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case 


Searching for the right CASE partner for your organization? 
Once you know what to look for, finding the right partner is 
elementary. All the evidence points to IDE. Its success formula 
combines the right CASE process, tools, training and support 
to make you successful. 


To implement your CASE strategy, start with UNIX— 
the proven choice of software developers. UNIX 
provides the best foundation for multi-user envi¬ 
ronments and offers the widest array of modern 
development tools. Most illuminating. 

Add IDE’s Software through Pictures® and 
your choice of other best-of-class tools such 
as Saber-C, FrameMaker and Interleaf. Software 
through Pictures integrates all these tools with a 
shared repository, supports structured and object- 
oriented methods, and runs over heterogeneous networks 
of Sun, Digital, HP and IBM workstations and X terminals. 
Closed products from other vendors fall far short of IDE’s open 
strategy. Why settle for a 7% solution when you can have it all? 

Look closely at your CASE alternatives and you’ll see why IDE 
is the obvious choice. Only IDE offers you open and extensible 
solutions such as the C Development Environment™ that guarante 
you can refine your CASE strategies to meet future requirements 
And if you’re just getting started with CASE, IDE’s Pilot Project 
Package provides all the software, training and support you 
need to make your first project a brilliant success. 

Fortuitous indeed. 
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NETWORK II.5 now predicts performance of 
computer-communication systems 

Free trial and, if you act now, free training 


N etwork 11.5 uses 

simulation to predict your 
network performance. You simply 
describe your network and work¬ 
load. 

Animated simulation follows im- 
mediately—no programming delays. 

Easy-to-understand results 

You get an animated picture of 
your network. System bottlenecks 
and changing levels of utilization 
are apparent. 

Seeing your network animated in¬ 
creases everyone’s understanding of 
its operation and builds confidence 
in your results. 

Your reports show response 
times, messages delivered, messages 
lost, device utilization, and queue¬ 
ing statistics. 

Computers with NETWORK II.5 

NETWORK II.5 is available for 
most PC’s, Workstations, and 
Mainframes. 


Your network simulated 

You can analyze embedded or 
distributed computer systems, or 
other computer-communication net¬ 
works. Industry standard protocols 
such as FDDI and IEEE Standard 
802.X are built-in. Others can be 
modeled. 

You can easily study the effect of 
changing network parameters or 
even network protocols. 

You can simulate some portions 
of the network at a detailed level 
and others at a coarser level. 

Free trial information 

The free trial contains everything 
you need to try NETWORK II.5® 
on your computer. For a limited 
time we also include free training 
—no cost, no obligation. 

Call Paul Gorman at (619) 
457-9681, Fax (619) 457-1184. In 
Europe, call Nigel McNamara, in 
the UK, on (081) 332-0122, Fax 
(081) 332-0112. In Canada, call 
Peter Holt on (613) 782-2474, Fax 
(613) 782-2202. 


Free trial offer 

I DYes I want to see how NETWORK II.5 
quickly answers network performance 
questions. 

Limited offer—Act now for free training. 
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New shell available 


To the Editor: 

William Mettrey’s article (“A Com¬ 
parative Evaluation of Expert System 
Tools,” Computer, February 1991, pp. 
19-31) compares five expert system 
shells. Unfortunately, he chose an old 
version of one of them, Level 5. 

The new version. Version 2, called 
Level 5 Object, has been available since 
June 1990 and is an object-oriented pro¬ 
gramming expert system product that 
runs under Windows 3. This new version 
incorporates both backward and forward 
chaining inference engines and can run 
in mixed mode. External database access 
and multiple inheritance is also sup¬ 
ported, as is a full graphic editor for 
user display development. 

Debugging tools include the Knowl¬ 
edge Tree, an interactive graphical en¬ 
vironment, and a session monitor with 
stepping, Breakpoint, and Session 
History. 

I would be interested in seeing an 
evaluation of these products with the 
new version of Level 5, Level 5 Object. 


Sample the standards! 

• Mozart, Bach, and Brahms 

• Jazz 

• Folk music, and 

• More 


Encounter new approaches! 

• Systems for machine composition 

• Composition languages 

• Pentatonic music, and 

• Music of the planets 


With your own 60-minute CD or cassette! 


Digitally recorded music on compact disk or Dolby B audiocassette presents 
project results as you read the articles. Order today so you can read 
COMPUTER with your earphones on. 


» magazine order form COMPUTER 

Address 

Qty. 

Total 

CD: $16* 



Tape: $12* 






Single issue price 

Country (member): $10 

Member Nn Nonmember: $20 



residents add 7% GST 



Mail to TOTAL (enclose full payment): 

IEEE Computer Society Order Dept. 

PO Box 3014 

Los Alamitos, CA 90720-1264 * Includes $4.00 postage ar 

id handling. 


Frank J. Noto 
Yorktown, New York 


Author’s reply: 

The article was written in the Febru- 
ary-March 1990 time frame, which was 
several months before Level 5 Object 
was available. It was submitted to 
Computer in May 1990 and accepted for 
publication in September 1990. 

Although I have had no direct experi¬ 
ence with the new version of Level 5, it 
is my understanding that it still does not 
support the Rete Matching Algorithm or 
equivalent functionality. If this is the 
case, I still would have to question its vi¬ 
ability for demanding forward-chaining 
systems. 

William Mettrey 


Computer welcomes your letters. 
Send to Letters Editor, Computer, 
10662 Los Vaqueros Circle, PO Box 
3014, Los Alamitos, CA 90720-1264. 

All submissions are subject to 
editing for style, length, and clarity. 
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Dennis Ritchie, legendary 
developer of the UNIX Operating 
System, puts it very simply: “The 
reason the original UNIX operating 
system was so small and elegant was 
because we did things that we really 
wanted to do.”* 

Although conventional UNIX has 
grown (literally) beyond Ritchie’s 
• original vision, many people still look 

to this classic OS to do what they 
want to do. 

But not if they want realtime 
performance. UNIX has unequalled 
power as a development tool, but you 
can forget about running realtime apps 
on conventional UNIX systems. They’re 
simply too big and too slow. 

Until now. 

Presenting QNX 4.0. The UNIX 
system that’s responsive enough for 
realtime apps, small enough for PC 
platforms, flexible enough for transpar¬ 
ent networking, and modular enough 
for the most demanding configurations. 

POSIX Means Portable 

UNIX systems come in more 
flavors than ice cream. Which is why 
IEEE’s POSIX standard is now such an 
important safeguard of portability. 


Quantum Software Systems Ltd. ■ 


At Quantum, we’re committed 
to the POSIX standard, and we’ve 
rewritten QNX to give developers a 
standard OS interface they can 
depend on. As a result, QNX is now 
a true UNIX operating system—but 
not a conventional one. 

Performance At Run Time, 
Design Time, All The Time 

Only QNX combines the perfor¬ 
mance of a dedicated realtime 
executive with the time-saving 
benefits of a rich UNIX development 
environment—including a host of 
utilities, an award-winning C compiler, 
and an optional OPEN LOOK™ GUI 
package. 

QNX is Distributed 

The QNX operating system lets 
you extend the limits of any one 
microprocessor. Whether you’re 


running a network of four or 400 
machines, QNX makes it all feel like a 
single computer. 

Interprocess communication is 
network-wide, so every process can 
transparently access every resource— 
programs, files, devices, even CPUs— 
anywhere on the network. And you 
can set up your network using any mix 
of Intel-based PCs. 

Responsive Tech Support 

Only QNX’s support hotline can 
put you in direct contact with the 
Technical Development team itself. 
And you’ll have access to our 24-hour 
online conferencing and update 
system, where the response time to 
your questions is almost like real time. 

“If Only...” 

Wherever computers do serious 
work for serious people, the UNIX 
operating system has made possible a 
lot of the “things we wanted to do.” 
But people who want realtime 
solutions have been waiting a 
long time to share in the benefits. 

The wait is over. 



What UNIX was meant to be. 

For more information, please phone (613) 591-0931. 
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information technology, and b) To carry out significant technology transfer with local and international 
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Specific projects cover Interactive Simulation, Hypermedia, Video, Image Processing, Scientific 
Visualization, Text Retrieval, Neural Networks, Fuzzy Logic, Computer-Aided Translation, High 
Speed Networks, Distributed Computing and Parallel Computing. The Institute has embarked on a 
number of joint projects with industry in Singapore and overseas. These include Computer Aided 
Translation with IBM; Pattern Recognition with the Port of Singapore Authority; Connectionist Expert 
System Shell with Singapore Airlines; and Text Abstraction with the Ministry of Defence. 

The ISS invites nominations and applications for ISS Fellow or Research Manager. 

Internationally eminent scientists will be appointed. Candidates for the positions must be capable of 
contributing significantly to the current research programs at the ISS, providing leadership in 
developing collaborative research with international corporations, research laboratories and universities. 
Applicants must have an outstanding research record and a commitment to the development of an 
internationally recognised research program. 

The ISS Fellow is a position equivalent to a Chair. One year appointments will be considered. 

The Reseach Manager is a senior management position. The candidate is likely to have directed major 
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E arly electronic document prepara¬ 
tion systems were batch-mode 
document compilers in which in¬ 
put looked quite different from the printed 
result. Debugging a document entailed a 
repetitious cycle of compile, print, walk to 
the printer, and look. WYSIWYG (what 
you see is what you get) editors were in¬ 
vented to speed this cycle. Much of the 
pioneering work on these editors was done 
in the Cedar system 1 and its predecessors at 
Xerox. Many people find this style of oper¬ 
ation more enjoyable and productive, and 
commercial WYSIWYG editors have won 
a major place in the market. 

But many users still will not use them. 
“What you see is all you get” is their com¬ 
mon complaint. WYSIWYG editors are 
convenient and visual, but today’s best 
document compilers are considerably more 
powerful. By providing programmability 
through a system of macros, Troff and Tex 2 
(pronounced “teck” and frequently typeset 
as “TjX”) offer highly automated format¬ 
ting with a fine degree of user control. 
Scribe 3 encourages the user to describe the 
structure of the document rather than the 
details of its appearance. The appearance 
of various structure elements can be de¬ 
scribed separately from the document, once 
and for all, in a style file, thus separating 
form from content. Latex, 4 an extensive 


By offering both 
WYSIWYG editing 
and language-based 
document description 
side by side, the Lilac 
document preparation 
system gives users the 
best of both worlds. 


system layered on top of Tex, combines 
both of these facilities. 

Instead of modeling a document as a 
long sequence of characters with various 
properties attached, structure-oriented 
document systems model it as a hierarchi¬ 
cal structure of units containing subunits. 
A common structure consists of chapters, 
sections, and paragraphs. Visual proper¬ 
ties, such as font, margins, and leading, are 
normally attached to characters implicitly 

0018-9162/91/0600-0007$01.00© 1991 IEEE 


as a result of their membership in some 
structure possessing those properties rath¬ 
er than by explicit attachment. Thus, a 
chapter title appears in a large font and is 
set off by a large region of white space not 
because it is surrounded by explicit com¬ 
mands to do so but because it is a chapter 
title. This styling information appears in 
the definition of chapters. Thus, we remove 
style information from the stream of text, 
and instead we bind style to structure. This 
suits the way authors naturally think about 
documents, and it allows the tasks of text 
creation and style design to be separated. 
Style design can be adopted from a style 
file written by an expert designer, and it 
can be globally modified without a pains¬ 
taking search-and-replace process. 

Lilac is an experimental document prep¬ 
aration system designed to provide the best 
of both the WYSIWYG and the document 
compiler worlds. It does this by offering 
both WYSIWYG editing and language- 
based document description as two views 
side by side on the screen (see Figure 1). 
The page view (right) is a WYSIWYG 
editor showing a close approximation to 
the printed output. The source view shows 
a program-like description of the docu¬ 
ment in a special-purpose language. This 
language supports subroutines, variables, 
and conditional execution and is designed 
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to encourage the use of subroutines to em¬ 
body structure. Both views are editable, but 
Lilac is designed with the expectation that 
most editing will occur in the page view. 

The two views are tightly coupled; any 
selection in the page view is also shown in 
the source view by a reflected selection, an 
underline that highlights the corresponding 
characters or expressions in the source view. 
Likewise, any editing action in the page 
view is reflected immediately in the source. 
Updates in the other direction are not auto¬ 
matic but are made rapidly upon user request. 

One of Lilac’s special contributions is 
that it supports user-definable document 
structure in a WYSIWYG editing context. 
The familiar structure of chapters, sections, 
and paragraphs is in no way hardwired into 
Lilac. All such features are defined by 
functions written in the Lilac source lan¬ 
guage. These functions specify the number 
and types of subunits — for example, the 
fact that a section has exactly one title but 
any number of paragraphs. A document 
type for producing slides could use an 
entirely different structure — slide, item, 
subitem — likewise defined by user-level 
programming. 

User-definable structure is important for 
handling various document types, but is 
perhaps more important for handling the 
great variety of special situations that arise 
within individual documents. A section of 
a technical book consists of paragraphs, 
but between and within those paragraphs 
may be displayed equations, tables, quo¬ 
tations, program examples, and other spe¬ 


cial structures. A particularly good exam¬ 
ple is a command description, such as might 
occur in the manual of a graphical editor: 

Flip Control-F 

Transform the selected object into its 
mirror image about a horizontal axis 
passing through its center. 

This special-purpose structure has three 
components — a command name, a key¬ 
binding, and a description — each with its 
own style. Though many document editors 
offer built-in support for equations, tables, 
and block quotations, no editor could rea¬ 
sonably be expected to support something 
so specialized as command descriptions. 
Nevertheless, it is convenient to be able to 
set up such a structure, with the name in 
boldface and the description indented be¬ 
neath it, and then fill in the text within that 
framework. 

Any attempt to combine the WYSIWYG 
and document compiler strategies must 
address three issues: 

• design of a WYSIWYG editor and user 
interface suitable for editing a document 
described by a program, 

• design of a suitable document descrip¬ 
tion language that can be implemented 
with the needed efficiency, and 

• implementation with adequate inter¬ 
active performance. 

This article deals primarily with editor and 
language design; implementation issues are 


briefly summarized. Interested readers can 
refer to the literature for details on design 
issues and the algorithms and optimiza¬ 
tions required to make the system run in 
real time. 5 

First I will describe the WYSIWYG ed¬ 
itor, along with the look and feel of the 
system. Readers who prefer to begin with a 
detailed technical foundation may wish to 
skip ahead to the section on language def¬ 
inition. 

The WYSIWYG editor 

The fact that a Lilac document is de¬ 
scribed by a program leads to some unusual 
challenges in designing a WYSIWYG ed¬ 
itor. The semantics of editing operations 
cannot be chosen simply to make a con¬ 
venient WYSIWYG editor; they must also 
be consistent with the structure and se¬ 
mantics of the source language. In effect, 
we are editing a program by editing its 
output. This gives rise to three new design 
problems: 

• keeping the source valid, 

• selecting in the presence of functions 
(definition versus reference), and 

• editing in a user-defined hierarchy. 

The first problem arises simply from 
having an underlying language. All editing 
operations must map into source changes 
that keep the source syntactically valid; 
they must not, for example, delete paren- 
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theses in an unbalanced fashion. The sec¬ 
ond problem arises from the presence of 
layout features automatically generated by 
functions. When pointing to a bullet (gen¬ 
erated by the bulleted-item function) in a 
bulleted list, does the user select this par¬ 
ticular bulleted item (the reference) or the 
prototypical bullet in the bulleted-item 
function definition? 

The third problem arises because Lilac 
functions allow the user great freedom in 
defining structure. One document may be 
organized as chapter-section-subsection- 
paragraph, while another may be slide¬ 
heading-subheading; the system designer 
can predict neither the set of structural 
elements nor the depth to which they may 
be nested. A user interface that presupposes 
a small and fixed set of object types and 
provides specific commands for each will 
not work. 

Keeping the source valid. We solve the 
problem of keeping the source syntactically 
valid by using structure-oriented editing. 
A three-way relationship is maintained: 
The source’s syntactic structure is used to 
represent the document’s logical structure, 
and the same structure underlies the se¬ 
mantics of the WYSIWY G editor. Because 
the source structure corresponds to logical 
structure, the structural constraints of the 
WYSIWYG editing framework make sense. 

In effect, the page view is an indirect 
syntax-directed editor. If one were to watch 
the source view while page-view 
(WYSIWYG) editing takes place, the ac¬ 
tions would appear to be precisely those of 
a syntax-directed editor. But in the space 
where editing is actually taking place, the 
controlling syntax is not evident but implicit. 

This strategy leads to certain restrictions 
common to syntax-directed editors. One 
can select multiple elements of a list but 
not multiple partial elements. Thus, one 
can select two paragraphs but not half of 
one paragraph and half of the next. There 
are also type-based restrictions; inserted 
material must be compatible with the type 
of the structure into which it is inserted. 

Definition versus reference. Lilac 
adopts a simple answer to the definition- 
versus-reference problem: Always operate 
on the reference. Function bodies are simply 
not accessible to page-view editing. Only 
function calls and other objects in the “main 
program” of the document are edited in the 
page view. This useful simplifying rule in 
the user interface prevents such accidents 
as unintentional global changes. It also 
prevents much confusion; where functions 


use doc. li 

defaults ■ 

rmargin = ,300 


Raise(-3, Hbox("E") ) , 
Hskip(-3) , "X") 


Vlist( 

Chapter ("A Chapter Title", 



?This sample document 


.."This paragraph shows ", 



Bold("boldface"), 

■ text and the fancy *, 


call other functions several levels deep, it 
could become quite difficult to understand 
what is being selected. 

Editing in a user-defined hierarchy. 

The third challenge, generalizing structure- 
based editing operations so that they work 
naturally and consistently in a user- 
defined structure, has occasioned the most 
innovations in the user interface. The de¬ 
sired features of such an interface are 

• easy selection of any syntactic element 
(subtree) in the hierarchy structure, 

• a smooth flow of typing as one fills in 
the text of the structure tree while 
writing, and 

• easy creation of new empty instances of 
user-defined structures and substruc¬ 
tures, including whole new documents. 

Selecting in a hierarchy. Lilac uses the 
familiar select-cut-paste model of editing, 
but selection is not as simple as in most 
systems. The selection mechanism must en¬ 
able the user to select any object in a hierar¬ 
chy of arbitrary depth, composition, and 
physical layout. A set of specific commands 
to select a paragraph, a section, a chapter, 
etc., will not work in this context; we need 
a more general mechanism. Lilac’s solution 
uses the following principles: 

• Selection begins at the lowest level of 
the hierarchy. 

• Higher levels are reached by promot¬ 
ing an existing selection. 


A Chapter Title 

A Section Title 

This sample document demonstrates 
the structure of Lilac documents. 

This paragraph shows italic and 
boldface text and the fancy QQ logo. 


Figure 2. Selecting the Tex logo. 


At any given level, more material is 
included by extending an existing se¬ 
lection. 

From these principles follow the three ba¬ 
sic selection operations of Lilac: Select, 
Promote, and Extend. Select chooses the 
smallest element under the mouse pointer 
— usually a single character. (A similar 
operation, Point, places an insertion point 
on whichever side of that element is closer.) 
Promote is designed for reaching higher 
levels of the hierarchy. It selects the struc¬ 
tural parent of the current selection. Ex¬ 
tend is for selecting multiple elements at 
the same level. Given an existing selection 
and a new mouse position pointing to an 
element within the same list, it will yield a 
new selection that includes the original 
selection, the new element, and any ele¬ 
ments that lie in between. 

Quick access to these commands is vital, 
so our configuration uses a three-button 
mouse, with Point, Select, and Extend bound 
to the three buttons. Promote is invoked by 
multiclicking the Select button; it is also 
available from the keyboard. 

Select. Select is usually quite straight¬ 
forward, simply selecting the character 
under the mouse. Occasionally it must se¬ 
lect more than just a character (see Figure 
2, for example, where the Tex logo is 
selected). Though the mouse may be point¬ 
ing at the E, the letter cannot be selected 
because it is part of a function definition. 
Instead, the call to the function (Tex) is 
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selected, and its entire value (the logo) is 
highlighted. Note the reflected selection 
(underline) in the source view. 

Promote. The Promote command raises 
a selection to the next higher level in the 
hierarchy. The lowest three levels — 


character, word, and string—operate within 
character strings. For ease of small-scale 
editing, they are built in, separate from the 
explicit syntactic hierarchy. Any further 
promotion is based on syntactic hierarchy: 
Promoting from a selected expression se¬ 
lects its parent expression. Any selection 


may be promoted repeatedly, selecting ever 
larger units, until the entire document is 
selected. The first click of the Select button 
on the mouse selects, and subsequent clicks 
within a short time promote the selection 
repeatedly. 

In Figure 3 the page view shows the 
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Figure 3. A sequence of promotions. 
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Figure 5. Promoting an insertion point. 


function Hbar = BlackBox(70. + 100 + 70 + 150 + 1, 1, .0) 

A horizontal bar, separating rows of the table 

function Vbar = Hlist(BlackBox(1, 14, 4), Hskip(4)) 

A vertical bar, separating fields within a row 

function ETRow (f ieldl©Hlist, f ield2 : Hlist, field3: Hlist, 
f ield4 : Hlist) = One row of the table 

Vlist( 

Hbox(HboxTo<70, Vbar, Bold(fieldl), hfill,, 

HboxTo(100, Vbar, field2, hfil), 

HboxTo(70, Vbar, field3, hfil), 

HboxTo (150, Vbar, field4, hfil), 

Hbar) Each row makes the horizontal bar below it 

function ElementTable (rows* : vlist) = Template for the whole table 

Center (Vbox (HBar, rows)) The table makes the first horizontal bar 


mouse pointing to the n in “Found.” We see 
five levels of a Select/Promote sequence as 
the user clicks the Select button five times. 
The entire sequence takes an experienced 
user about 1 second. Figure 4 shows the 
definitions for the structure underlying 
Figure 3. 

Promotion is one of the ways Lilac dif¬ 
fers most from standard WYSIWYG edi¬ 
tors. Other systems support selection of 
character or word sequences, and the best 
of them offer convenient ways to select 
whole lines and paragraphs. But most ed¬ 
itors provide no facility for selecting at 
higher levels, and none fully support a 
general user-defined structure. 

Point. Point is similar to Select, but 
instead of selecting an object, it places an 
insertion point before or after it. Point has 
an associated promotion operator, UpFor- 
ward, which places an insertion point after 
the containing structure at the next higher 
level. It can be invoked by multiclicking 
the Point button, or from the keyboard. 

Figure 5 illustrates a Point/UpForward 
sequence, invoked by clicking twice while 
the mouse points to the right of the period 
after the word “documents.” Lilac uses its 
type system to help distinguish insertion 
points. Because the second insertion point 
occurs in a vertical list, it appears as a 
horizontal blinking bar. The vertical bar in 
the source view is a reflected insertion 
point; it does not blink and is thereby dis¬ 
tinguished from an actual insertion point. 

Extend. Extend creates a selection of 
contiguous elements of one list. The existing 
selection or insertion point marks one end; 
the mouse position marks the other. The 
new selection is at the same structural level 
as the original but contains more elements. 
To maintain consistency in structure-based 
editing, a fixed-element selection (see 
sidebar on next page) cannot be extended, 
and no selection can be extended outside 
its containing list. 

Without further help, these restrictions 
would often be frustrating, so we provide 
the PromoteExtend command, invoked by 
double-clicking the Extend button. Where 
Extend produces a selection at the same 
level as the original, PromoteExtend pro¬ 
motes the level as far as necessary to pro¬ 
duce a selection that includes both end¬ 
points. 

For example, in the fourth stage of Figure 
3, the first row is selected. At this point, an 
Extend click anywhere in the second row 
will extend the selection to include this row 
as well. This contrasts with the first stage of 


Figure 4. The definitions for Figure 3. 


Figure 3, where the selection is in the char¬ 
acter string occupying the fourth cell of the 
first row. Here, an Extend to the second row 
will fail because neither the characters nor 
the row itself is in the same list with the 
original selection. PromoteExtend will se¬ 
lect both rows in their entirety. 

Smooth flow of typing. The cut-and- 
paste model is a good method for editing 
within existing structures — and a very bad 
method for extending them. Consider the 


steps required to create a new paragraph, 
assuming an existing one can be found: 

(1) Select the old paragraph 

(2) Copy 

(3) Put a vertical insertion point where 
the new paragraph should go 

(4) Paste 

(5) Select the characters in the new copy 

(6) Cut 

Now, finally, a new, empty paragraph is 
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Syntax and structure 

Lilac functions have two kinds of formal arguments: normal arguments, which 
accept precisely one actual argument, and repeatable arguments, which accept 
any number of actual arguments. A normal argument gives rise to a fixed-ele¬ 
ment slot in the structure; a repeatable argument gives rise to a list slot. List ele¬ 
ments can be selected singly or in contiguous groups; they can be inserted, de¬ 
leted, replaced, split, and joined. Fixed elements can only be selected singly; 
they cannot be inserted or deleted, only replaced. This guarantees that no func¬ 
tion call will end up with an inappropriate number of arguments or have its argu¬ 
ments shifted into inappropriate positions. A literal character string is treated as 
a special sort of list. 

The figure in this sidebar shows a typical version of the Chapter function. It 
takes a title (a normal argument) and a body (a repeatable argument indicated 
by an asterisk). In the example below the function definition, the title string, “Ba¬ 
sic Concepts,” is a fixed element. It cannot be deleted; however, its characters 
could be deleted, leaving an empty string. The sections, by contrast, form a list. 
Any or all of them could be entirely deleted. (The details of the language and its 
operators are discussed later in the main text.) 


The Chapter function 


function chapter(title: @Hlist 

body*: Vlist) = 

- Vlist(Center(Sizel8(title)), 

Title is centered in 18-point font 

Vskip<24), 

Vertical glue, 24 points high 

body, 


Vskip(24)) 


A typical chapter 


Chapter! "Basic Concepts", 


Section(...) , 





The Chapter function and its use. 


ready to receive content. As a normal mode 
of operation, this is clearly unacceptable. 
While creating within ordinary and 
straightforward structures, the user should 
be able to keep right on typing, performing 
a minimum of special operations. Since 
“paragraph” itself is a user-defined struc¬ 
ture and could have many user-defined 
variations, we dare not build any special 
knowledge of paragraphs into the editor, 
such as “the Return key starts a new para¬ 
graph.” A more general mechanism is re¬ 
quired. 

The Return key is a good place to focus 
our attention. Intuitively speaking, it should 
make a new, empty instance of whatever 
structure the user is already working in. 
Certainly, if the user is making paragraphs, 
it should create a new, empty paragraph. 
As a general approach to this need, Lilac 


introduces the concept of empty replica¬ 
tion: Given an existing object, make a 
replica that has the same structure but none 
of the content. The empty replication algo¬ 
rithm is recursive, as follows: 

(1) Copy the outermost level of the ex¬ 
pression. 

(2) In place of any character string in 
the original, put an empty string in 
the copy. 

(3) In place of any list, put an empty 
replica of the first element of the list. 

(4) In place of any fixed element, put an 
empty replica of that element. 

(5) Copy numeric and other intangible 
arguments intact. 

We replicate the first element of a list to 
preserve substructure — for example, the 


fact that a section body consists of para¬ 
graphs. 

The Return key, then, uses the following 
algorithm: 

(1) Find the nearest ancestor of the cur¬ 
rent selection or insertion point that 
is a vertical list element. 

(2) Make an empty replica of it. 

(3) Insert that replica immediately after 
the original. 

(4) Place an insertion point in the first 
text field in the replica. 

This produces results that match our intu¬ 
itive expectations of what a Return key 
should do. If the user was typing in a 
paragraph, it starts a new paragraph below 
the first. If the user was typing in a centered 
line, it starts a new centered line below the 
first. If the user was typing in a specially 
offset paragraph with indented margins 
and a special font, the Return key starts a 
new paragraph with all those properties. 

Return can also extend structure at high¬ 
er levels. Suppose the user is typing in a 
paragraph of a document with a chapter- 
section-paragraph structure. Pressing Re¬ 
turn will produce a new paragraph. How¬ 
ever, by first invoking UpForward, the 
user produces an insertion point at paragraph 
level immediately below the current para¬ 
graph. Its parent is the section, so pressing 
Return now will produce a new section. 
Invoking UpForward twice would place 
the insertion point at the section level, and 
pressing Return would yield a new chapter. 

Unlike Paragraph, the Chapter and Sec¬ 
tion functions take more than one argu¬ 
ment — in this case, title and body. To 
provide easy movement from one argument 
to the next, we use the Tab key. Starting 
from the current selection or insertion point, 
it finds the next character string in the 
document and puts an insertion point there. 
Repeated use of Tab will visit every string 
from the current selection to the end of the 
document. This is useful for hopping from 
field to field, and it is vital for reaching 
empty strings, which may not be accessible 
by mouse because they take up no space on 
the screen. 

The table from Figures 3 and 4 shows the 
power of the Return and Tab commands. 
This is a good example because it deals 
with a totally user-defined structure far 
removed from the structure of ordinary 
text. Instead of a section consisting of 
paragraphs, we have an ElementTable 
consisting of ETRows, each consisting of 
exactly four cells. Suppose the user puts an 
insertion point at “diamonds” and presses 
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Return. The string “diamonds” is a fixed 
element, not a list element, so it is not 
eligible for replication. We look up a level. 
The ETRow is a vertical list element under 
Vlist, so it is eligible. We replicate it and 
put an empty string in place of each of the 
four character strings. A new, empty row 
appears below the Carbon row, with an 
insertion point in the first field (see Figure 
6). With a quick sequence of keystrokes 
the user can fill it. Thus the table, unusual 
structure though it is, can be extended 
indefinitely by ordinary typing. And so can 
all structures composed of fixed elements 
and homogeneous lists. 

First instances. Return and Tab are ex¬ 
cellent for extending a table, but they could 
not have produced the first instance of a 
Table Row. Othermeans are required. Many 
editors solve this problem by providing a 
set of “New X” commands for various 
kinds of X. Some of these may be desirable 
in Lilac, but they will never solve the 
problem. The set of things that might be 
inserted is unbounded and user extensible. 
A menu of New X commands would be 
useful, but it would have to be designed 
with human involvement and probably 
stored in the style file, with means provided 
for the user to add to it. An automatically 
generated menu of all functions would in¬ 
clude many subroutines not intended for 
direct use by users and would be so large as 
to be unusable. 

An alternative, of course, is to work in 
the source view. But experience shows this 
to be cumbersome and error-prone com¬ 
pared with the intuitive simplicity of 
pointing and acting in the WYSIWYG 
context. So Lilac provides another option: 
hybrid commands. The most important of 
these is Insert. It pops up a special input 
field above the page view, allowing the 
user to type a source-language expression 
describing the object to be inserted. Once 
this expression is correctly parsed, the re¬ 
sulting object is inserted at the insertion 
point or selection in the page view, just as 
if it had been cut and pasted. 

This strategy proves very useful, pri¬ 
marily because the page view offers much 
better cues for spatial orientation. The spatial 
cues of WYSIWYG editing and the power 
of language are smoothly combined, re¬ 
sulting in a minimum of visual disruption. 

Another use for hybrid commands is in 
local style changes. Local variations in 
styling are effected by style functions, which 
take a single argument and evaluate it in a 
modified environment. Examples are Bold, 
Italic, Size 10 (which uses a 10-point font 


The user types: 

O <Tab> Oxygen <Tab> 8 <Tab> air 
| O | Oxygen | 8 | air 


Figure 6. Extending a table by ordi¬ 
nary typing. 


size), and SingleSpace (which sets a nar¬ 
row spacing between lines). 

The styling command transforms the 
source by wrapping the selected material 
in a call to the appropriate styling function. 
Quoted strings are broken up as necessary. 
(Figure 7 provides an example.) If the 
selection is just an insertion point, the 
styling function is wrapped around an empty 
string and the new insertion point is placed 
inside it. 

The Bold and Italic styling commands 
are available from the keyboard. But here, 
as with insertion, the set of relevant func¬ 
tions is infinite and user extensible. So a 
hybrid command is also provided, allow¬ 
ing the user to directly specify the function 
to be wrapped around the selected text. 

New documents. A completely empty 
new document, starting with an empty 
source view, could not even support a page 
view because it has no main program. But 
what ordinary users will want is a page 
view with an empty prototypical structure 
already set up and suited to the type of 
document being created. 

This is provided by a means similar to 
the empty replication of expressions. 
Starting with an existing document, the 
user gives a New Document command that 
means “Create a new document of the same 
type as this one.” After creating the new 
document, this command copies the style 
file references from the header of the orig¬ 


inal document. By including the same style 
files, we get a document of the same type. 
One of the things a style file usually spec¬ 
ifies is a new document template. This is 
copied to become the initial main program 
for the new document. The new document 
template for our standard book style looks 
like this: 

unit newdoc = 

Document( 

Chapter(“”, 

Section(“”, 

Para(“”)))) 

The resulting page view comes up blank, 
but the empty chapter title, section title, 
and paragraph fields are in place and 
reachable by mouse. The initial type-in 
point sits in the chapter title, so the whole 
structure can be filled in by typing and 
tabbing between fields. 

This facility applies not only to simple 
models but also to documents far more 
stylized and complex. Style files can be 
created with the prepackaged structure for 
a business letter, a resume, an invitation 
(complete with beautiful fonts in appropri¬ 
ate places), and many other types. If satis¬ 
fied with the structure and styling provid¬ 
ed, a user can type the complete document 
without ever touching the source view or 
the mouse. 

This ease of use addresses a frequently 
asked question: “Why should I want to 
learn a special language when there are 
simpler ways to get the job done?” In fact, 
ordinary users doing straightforward tasks 
do not need to learn the language or use the 
source view at all. On the other hand, many 
will want a basic reading knowledge of the 
language so that they can use the source 
view for occasional reference. And style 
designers or users with unusual layout re¬ 
quirements will need to learn it thorough¬ 
ly. It is the job of the style designer to 
provide a sufficiently complete set of facil¬ 
ities so that ordinary users don’t have to do 
any programming. 



Source view 


Page view 

Before: 

"an emphasized word" 


an emphasized word 

After: 

"an", Italic("emphasized"), 


an emphasized word 


Figure 7. Transformation in the source view and the page view by a styling com¬ 
mand. 
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The document 
description language 

The Lilac document language is designed 
to support user-definable structure, to serve 
as a basis for two-view editing, and to be 
clean, logical, and readable. To help make 
it clean and logical, I have broken with 
tradition and avoided the use of textual 


substitution macros. Instead, Lilac is more 
like a programming language: It uses func¬ 
tions as the basic mechanism of program¬ 
ming and structuring. The language is 
strongly typed; a function takes arguments 
with definite types and returns a value with 
a definite type. 

The relationship between the Lilac lan¬ 
guage and document structure is best de¬ 
scribed by borrowing some terms from the 


Office Document Architecture (ODA) 
standard. A document has two structures: a 
logical structure consisting of the abstract 
units into which it is organized (chapters, 
etc.), and a layout, that is, its physical 
arrangement on a particular medium (usu¬ 
ally pages). (This article refers to logical 
structure simply as structure.) Generic 
structure defines the set of logical objects 
available and the permissible relationships 
among them. Specific structure is a par¬ 
ticular hierarchy of specific instances of 
these objects. Generic layout specifies as¬ 
pects of layout that are in common over all 
or a range of pages (margins, position of 
page number, etc.). A layout style specifies 
aspects of layout that are governed by 
particular pieces of generic logical struc¬ 
ture (such as the font of chapter titles). 
Specific layout is the precise arrangement 
of a particular document on pages; it is 
usually derived from the aforementioned 
sources of information by formatting. 

The Lilac language, then, represents 
document structure as follows: 

• Generic structure is specified in the header 
of function definitions. Each function de¬ 
fines a structural element type; the parame¬ 
ters and their types specify its substructure. 

• Layout style is specified in the body of 
function definitions. To change the styling 
of that element type, a function definition 
can be overridden with a new definition that 
has the same header and a different body. 

• Generic layout is specified in a special 
function called the page model. Given the 
raw output of a page-breaking operation, 
this function produces a page as a precisely 
laid-out box, which may include additions 
such as headers and footers. 

• Specific structure appears in the main 
program, which takes the form of an ex¬ 
pression made up mostly of nested function 
calls. Within the main program, each 
function call specifies one instance of the 
element type defined by that function. The 
arguments to the call are the subunits be¬ 
low it in the hierarchy. 

• The content of the document appears 
in character string literals, usually within 
the main program. These are the most 
common form of primitive expression. 
Character strings usually enclose text at 
the paragraph level; lower levels of struc¬ 
ture are not explicitly represented. 

Below, I describe the organization of doc¬ 
uments in Lilac, the grammar, and the type 
system, and then I highlight those features in 
which Lilac differs from typical formatter 
languages and programming languages. 


Grammar of the Lilac language 

Nonterminals: 


Document 

= Imports Defaults Definitions 

Imports 

= {Import newline } 

Import 

= use FilelD 

Defaults 

= { Assignment newline } 

Assignment 

= Id '=’ Expr 

Definitions 

= { Definition newline } 

Definition 

= function Id [ ‘(‘ FormalParams “)’] V Expr 


1 unit Id =’ Expr 

FormalParams 

= FormalParam { 7 FormalParam } 

FormalParam 

= Id [ '*’ ] Type 

Type 

= PrimType 1 PrimType 

Expr 

:= Number 1 String 1 Variable 1 Call 1 ArithExpr 1 


•{• Expr *)’ 1 LetExpr 1 LocalExpr 1 IfExpr 

Variable 

= id 

Call 

= Id [ •(• Arguments ')’ ] 

Arguments 

= Expr { 7 Expr } 

ArithExpr 

:= Expr Binop Expr 1Expr 1 not Expr 

LetExpr 

= let Assignments in Expr 

Local Expr 

= local Assignments in Expr 

Assignments 

= Assignment { 7 Assignment } 

IfExpr 

:= if Expr then Expr else Expr 

Terminals: 


Number A number, optionally including a decimal point and frac¬ 

tional digits. 

String A string of characters surrounded by double quotes. 

FilelD A filename of any syntax acceptable to the system, pro¬ 

vided it does not start or end with a blank or include new¬ 

lines. 

PrimType One of the system types, listed in sidebar on page 15. 

Binop One of: +-*/% = #><>= <= and or 

Metasyntax: 


[ ] Surround an optional element. 

{} Surround an element that may occur zero or more times. 

1 Separates alternatives. 

boldface Indicates keywords that appear literally in the syntax. 
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Document organization. The sidebar on 
page 14 provides a grammar of the Lilac 
language. A Lilac document description 
consists of three sections (any of which may 
be absent): imports, defaults, and defini¬ 
tions. The imports section consists of “use” 
directives, each naming a style file — a 
separate document that defines standard 
functions and provides standard values for 
style parameters such as font, margins, spac¬ 
ing, etc. The defaults section consists of 
assignments, which specify the initial val¬ 
ues of global variables. Here, new global 
variables may be created by assignment. 

The definitions section includes user- 
defined functions and the body of the 
document. Two kinds of objects are defined 
here. A function may take arguments and is 
expected to be called more than once. A 
unit takes no arguments and is expected to 
be called only once. Functions are for de¬ 
fining structure elements; units contain the 
textual content of the document. This dis¬ 
tinction is crucial for the page-view-editor 
policy: “Edit the reference, not the defini¬ 
tion.” The top-level unit of a document is 
named “main.” A style file differs from a 
normal document in having no main unit. 

For a concrete example of document 
organization, see Figure 2. The imports 
section brings in the standard style file 
“doc.li,” which defines, among other things, 
the Chapter, Section, Italic, and Bold 
functions. In the defaults section, we assign 
a value to “rmargin,” thus overriding the 
standard right-margin setting. The value 
300 is unusually small, allowing the output 
to fit in the box we have provided. 

Next comes the definitions section, be¬ 
ginning with the user-defined function Tex. 
This function generates the Tex logo. The 
second definition is the unit “main,” which 
contains the body of the document. In¬ 
dentation, which the source-view pretty- 
printer maintains automatically, clearly 
shows the hierarchical structure of the text 
within the unit. 

While most formatter languages mark 
programming constructs by escape se¬ 
quences within the running text. Lilac puts 
the text in quoted strings and the pro¬ 
gramming constructs on the outside. This 
works well because the page view provides 
a good place to read the text, leaving the 
source view as a place to emphasize clarity 
of programming and structure. 

Types and semantics. The type system 
and semantics of the language are based on 
boxes and glue, a concept borrowed from 
Tex. For readers unfamiliar with Tex, a 
box is a rectangular object describing cer¬ 


tain black marks (ink) to be placed on the 
page. Boxes can be joined to create hori¬ 
zontal and vertical lists; such lists can be 
boxed to form larger, composite boxes. In 
these lists, boxes are often separated by an 
invisible, stretchy material called glue, used 
to describe spacing. Glue has three prop¬ 
erties: natural size, stretchability, and 
shrinkability. 

The fundamental operation on these ob¬ 
jects is the building of boxes. Boxing a list 
transforms it from a flexible object of inde¬ 
terminate dimensions into a solid object of 
definite, fixed dimensions. This can be 
done without specifying length (in which 
case all glue receives its natural size), or to 
a specified length. When the specified length 
is different from the sum of natural lengths, 
each item of glue stretches or shrinks — in 
proportion to its stretchability or shrink¬ 
ability — as far as necessary to achieve the 
specified size. This flexibility allows para¬ 
graphs to be justified. 

The types in Lilac form a fixed set, as 
shown in the sidebar below. Box, Hglue, 
and Vglue objects are the things that can be 


built into lists; these are referred to ge- 
nerically as “items.” The types Hlist and 
Vlist represent lists themselves; these are 
referred to as “list types.” 

Besides the operations shown in the 
sidebar, there is the important implicit 
operation of character string conversion. 
Character string literals are not just con¬ 
stants but executable expressions of type 
Hlist. Execution converts the raw charac¬ 
ters into a list of words (boxes) and spaces 
(glue), built using the font specified by the 
current value of the “font” variable. 

Repeatable arguments. A Lilac func¬ 
tion consists of a header, which describes 
the formal arguments and their types, and 
a body, an expression that computes the 
value of the function. The last argument, if 
it is of a list type, may be marked with an 
asterisk to indicate that it is repeatable. A 
repeatable argument can match zero or 
more actual arguments in a call. These may 
be of its own type or of any type that is 
acceptable as an element of a list of that 
type. When the call is executed, the values 


Lilac types and some basic operations 

Types: 

Box A box 

Hglue An item of horizontal glue 
Vglue An item of vertical glue 

Hlist A horizontal list 

Vlist A vertical list 


Num A number (fractions are supported) 

Bool A Boolean value — either true or false 

Family A font family (Times, Helvetica, etc.) 

Face Plain, Italic, Bold, or Boldltalic 

Font A font (that is, a particular family, face, and size) 


Some basic operations on boxes and 
Hbox(list: Hlist): Box 
HboxTo(width: Int, list: Hlist): Box 

Vbox(list: Vlist): Box 
VboxTo(size: Int, list: Vlist): Box 
Hlist(items): Hlist 

Vlist(items): Vlist 

Para(list: Hlist): Vlist 


Box a horizontal list, to natural width. 

Box a horizontal list, to the specified 
width. 

Box a vertical list, to natural height. 

Box a vertical list, to the specified height. 
Build a horizontal list out of Box and 
Hglue items. 

Build a vertical list out of Box and Vglue 
items. 

Break a horizontal list into lines and justi¬ 
fy them, yielding a vertical list consisting 
of lines and interline glue. 
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view view 



Figure 8. Structure of the implementa¬ 
tion. 


of the repeatable arguments are automati¬ 
cally concatenated into a single list, which 
becomes the value of the repeatable formal 
argument. Repeatable arguments are the 
mechanism for expressing all repetitive 
structures in Lilac — sections in a chapter, 
paragraphs in a section, etc. 

Functional language model. The Li¬ 
lac language appears purely functional at 
first. There is no assignment statement 
(except for assigning initial values to global 
variables), and functions have no side 
effects. This restriction is necessary to 
build an efficient implementation. 
(Asente, 6 who built a two-view editor for 
graphics, discovered this same require¬ 
ment.) In a normal programming language, 
where side effects are permitted, a change 
to one expression may affect the value of 
any expression executed thereafter. To 
correctly update the screen in response to 
an editing action, we would need to re- 
execute a major fraction of the entire 
document or do some costly variable-usage 
analysis to prove that such effort is un¬ 
necessary. But in a functional language, a 
change to one expression can affect only 
its dynamic ancestors—expressions whose 
execution is in progress when it is executed. 
This is a vastly reduced task and can be 
done in an acceptable amount of time. The 
need for a functional language was the 
primary reason for designing a new doc¬ 
ument description language for Lilac. 
Otherwise, Tex would have been the ob¬ 
vious choice. 

A purely functional language is not en¬ 
tirely adequate to express all the complex¬ 
ities of a document. It falls short when 
dealing with features that cut across the 
basic hierarchical structure — for exam¬ 
ple, floating figures, footnotes, cross- 
references, and numberings. Later I dis¬ 


cuss strategies for supporting these fea¬ 
tures within the Lilac framework. 

Dynamic variables. While we need a 
functional language, we also need global 
variables. Typesetting is full of style pa¬ 
rameters, which are frequently used but 
seldom changed; examples include font, 
margins, paragraph indentation, and lead¬ 
ing. To pass all these as explicit arguments 
would be intolerable, so to handle these 
style parameters within a functional context. 
Lilac uses global variables with dynamic 
scoping. Such variables have their “perma¬ 
nent” values assigned in the defaults sec¬ 
tion at the outset. All other assignments are 
temporary and explicitly scoped, using the 
“let” construct. For example, 

let font = TimesRoman9, lmargin = 80, 

rmargin = 360 in Para(...) 

This typesets the paragraph with the spec¬ 
ified font and margins. A “let” expression 
assigns values to one or more environment 
variables and evaluates its body with those 
assignments in effect. The new values ap¬ 
ply during evaluation of that expression or 
of any function called from it. As soon as 
evaluation is complete, those variables re¬ 
vert to the values they had before evalua¬ 
tion of the “let” expression began. 

Call-by-name arguments. It is not 

enough to have a “let” construct to modify 
styling. To bind style to structure, we need 
to impart this power to functions as well. In 
the Lilac context, this means that functions 
should be able to apply styling to their 
arguments. For example, the Chapter func¬ 
tion should set the font of the title. In 
addition, we want pure styling functions 
such as Italic(text), Bold(text), or 
DoubleSpace(paragraph). 

Ordinary function semantics will not suf¬ 
fice. A function argument is evaluated be¬ 
fore the function is invoked, so no “let” 
expression inside the function could influ¬ 
ence the environment of the argument. 
Therefore, in Lilac we allow call-by-name 
arguments. Any formal parameter whose 
type is marked with an @ sign is a call-by- 
name, or unevaluated, argument. Such an 
argument is not evaluated before the func¬ 
tion call but during it, at the point of use. If 
used more than once, it is evaluated more 
than once. An example is the definition of 
the Italic function (somewhat simplified 
here). 

function Italic(stuff: @Hlist) = 

let font = ItalicFont in stuff 


The argument “stuff’ is defined to be an 
unevaluated argument of type Hlist. What 
is passed at the time of call is not an Hlist 
but rather a reference to an expression 
whose evaluation will produce an Hlist. 
That expression is evaluated during execu¬ 
tion of Italic, while font is bound to 
ItalicFont. Thus, Italic returns an Hlist in 
which all text has been converted into box¬ 
es and glue using ItalicFont. 

Two-view editing. With this under¬ 
standing of the language, we can now ex¬ 
amine the two-view editing interface. As 
mentioned earlier, all selections and mod¬ 
ifications to the page view are made imme¬ 
diately in the source view as well. This 
cannot be done for source-view modifica¬ 
tions, since many keystrokes may produce 
a syntactically incomplete source. 

The source view is a free-form text edi¬ 
tor. Source-view changes take effect in the 
page view after a Reparse, which checks 
for correct syntax. Reparsing also pretty- 
prints, so free-form editing does not im¬ 
pose a burden on the user to maintain 
formatting conventions. Reparse is incre¬ 
mental: It discovers which parts of the text 
have been edited, maps those changes into 
transformations on the underlying struc¬ 
ture, and updates the corresponding parts 
of the page view. However, when the only 
edits have been to function definitions, 
there is no simple correspondence. Precise 
correctness would require recomputation 
of every call to that function, but these 
would be difficult to enumerate and time- 
consuming to perform. So we allow the 
user to specify a selected part of the docu¬ 
ment as the “region of interest.” During a 
Reparse after edits to definitions, only this 
part is updated in the page view. This 
strategy provides a fast-turnaround work¬ 
ing mode for function editing and testing; 
when the results are satisfactory, a Recom¬ 
pute command updates the page view to 
reflect the changes throughout. 

Implementation 

Lilac was built at the DEC Systems 
Research Center. It is implemented in 
Modula-2+ and runs on the Firefly exper¬ 
imental workstation under the Topaz op¬ 
erating system and the Trestle window 
system. This article discusses implementa¬ 
tion only briefly; the algorithms are dis¬ 
cussed extensively elsewhere. 5 

Figure 8 shows the implementation’s 
basic structure. Each view is supported by 
a hierarchical data structure that bears a 
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close relationship to the image on the screen. 
Underlying the source view is the syntax 
tree, a parse tree of the source program 
augmented with enough information to al¬ 
low it to be unparsed in a prettyprinted 
format. The syntax tree is the ultimate 
repository of truth; all other data structures 
and views can be derived from it. Under¬ 
lying the page view is the display list, a tree 
corresponding to the hierarchy of boxes and 
glue. There is one node (“item”) for each 
box or piece of glue; to each composite box 
is attached the list of its component items. 

Display list items are the values generat¬ 
ed by interpreting the syntax tree. The 
value of the unit “main” is the display list 
of the entire document. The system’s re¬ 
sponse to an editing operation is to re¬ 
interpret the document to update the display 
list and then use the new display list to 
update the screen. 

The central strategy for achieving speed 
is incremental interpretation. The editor notes 
which node or nodes in the syntax tree are 
affected by a change. Thus the interpreter 
reinterprets only the modified nodes and 
their direct ancestors, not the entire tree. 
The values of unaffected brother nodes are 
retrieved from a hash table. This is made 
possible by the use of a functional language, 
which guarantees that no side effects from a 
modified node can reach nodes other than 
its ancestors (callers). 

Besides the basic incremental interpre¬ 
tation paradigm, special incremental 
strategies are implemented for the most 
common time-consuming operations: 
conversion of text to display lists, concat¬ 
enation of lists, and line-breaking of para¬ 
graphs. In particular, lists are implemented 
such that they can be concatenated without 
losing their identity; thus, without copy¬ 
ing, a list can be both stored in the hash 
table and concatenated into a larger list. 

In storing the value of every node in the 
tree, the hash table serves a second pur¬ 
pose. It supports source-to-output map¬ 
ping so that the editor can find and high¬ 
light the display list items corresponding 
to a selected syntax tree node. The inverse 
mapping is done by storing source pointers 
in display list items when they are created; 
thus the editor can trace a mouse position 
through the display list to the relevant node 
to select it. 

Performance. Lilac is written in Modu¬ 
la-2-!-. Performance results were obtained 
on a Firefly workstation, a symmetric mul¬ 
tiprocessor consisting of four MicroVAX 
III processors (roughly 2 MIPS each). Lilac 
does not use concurrency internally, so the 


only advantage gained from multiprocess¬ 
ing is some overlap with operating system 
and window system operations. The work¬ 
station uses a bitmapped display with hard¬ 
ware support for text-painting operations. 

The measurements in Table 1 were ob¬ 
tained for a 15-page document with 35 
Kbytes of source language text. Localized 
measurements were taken in ordinary 
running text, four structural levels deep. 
Times are in CPU seconds, not including 
work done by the operating system and the 
window server. 

Analysis and future 
directions 

Lilac, as described here, is a prototype 
built as a doctoral dissertation project. Many 
things that would be done in building a 
full-scale system were left undone, and 
some interesting avenues of research were 
left unexplored. To date, Lilac has had one 
serious user, the author, who used it to 
produce a doctoral dissertation as well as 
drafts of this article. This was by no means 
a sufficient test, but it revealed many ad¬ 
vantages, shortcomings, and opportunities 
for improvement. 

First and foremost. Lilac works. The 
original performance goal was to handle 10 
keystrokes per second in ordinary running 
text. As originally tested on a workstation 
consisting of five 1-MIPS MicroVAX II 
processors, it achieved this goal for docu¬ 
ments of up to 20 pages. On today’s work¬ 
stations of 20 MIPS and greater, algorithm 
performance will be entirely adequate. 

Two-view editing. Experience with the 
system leads to the surprising conclusion 
that two-view editing is not for everyday 
use in word processing. In other domains, 
such as VLSI layout and graphical user 
interface layout, two views are frequently 
useful. But in word processing, the volume 
of source is so great and has so much 
overlap with the text in the page view that 
the source view is cumbersome for com¬ 
mon operations, and one finds it desirable 
to turn all common operations into page- 
view commands. This leaves the source 
view functioning as a special tool for special 
tasks — either for building one-of-a-kind 
structures, such as unusual tables, or for 
doing style design and debugging. For style 
debugging, it is exceedingly valuable, and 
a 1-second turnaround loop on simple 
changes is a great benefit. Occasionally it 
is useful for navigation, when structures 


Table 1. Time in CPU seconds for vari¬ 
ous activities. 


Activity 

Time 

Type one character 

0.059 

Select a character by 

0.040 

mouse 


Return/new paragraph 

0.182 

Display next page 

0.074 

Open the document 

9.90 


are so deep or complex that the page view 
gets confusing. Thus, I conclude that a 
source view with reflected selections is 
indeed useful, but there is no need to up¬ 
date its contents on every keystroke. If it 
took a second or two to update on request, 
that would suffice. 

While two-view editing is not as impor¬ 
tant as originally expected, the presence of 
a user-accessible underlying language is 
crucial. It provides a means of escape from 
the system’s model of document structure, 
as it provides the ability to encode complex 
user-defined structures. This ability allows 
the creation of style files that embody all 
the inherent structure of a document as 
specialized as a resume or a business letter. 
The user of such a style file need only type 
the content and use the Tab key to move 
between fields. User-defined structures are 
also valuable in documents with special 
needs, such as manuals, where they are 
very effective for handling examples, com¬ 
mand descriptions, and the like. This func¬ 
tionality greatly exceeds what the paragraph 
style sheets found in commercial word 
processing programs can provide. The two- 
view methodology has since been applied to 
the task of graphical user interface layout 
and has proved quite effective. 7 

User interface. Lilac’s solutions to the 
user interface challenges have various 
strengths and weaknesses. The Return key 
mechanism works well — as long as the 
document structure is homogeneous. Where 
it consists of alternating structures, such as 
running text interspersed with displayed 
mathematical formulas, creating new pieces 
becomes clumsy. User-tailorable menus 
and keybindings are clearly needed, and 
the user profile should be able to specify 
them on a per-document-type basis. In 
conjunction with this, an extension of the 
“new document template” concept would 
be useful. Along with the definition of a 
new element class, the language should 
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Other two-view systems 


The first two-view editor that came to my attention was a VLSI layout editor 
called Sam, built by Trimberger. 1 He invented the concept of reflected selections 
and found them extremely useful in helping users retain context between the two 
views. A more recent system, Tweedle, 2 uses a procedural language as source- 
view material for a general-purpose graphics editor. Tweedle is very nearly a 
graphics-editor analog of Lilac. 

There are several document editors with goals similar to Lilac’s. These sys¬ 
tems differ from standard WYSIWYG editors in that they allow the user to create 
generic structure. They differ among themselves in the degree to which one can 
use a single language to describe generic structure, layout styles, and the other 
aspects of document information. They also differ in the kind of language used 
and in the degree to which that language is available for direct editing. For com¬ 
parison, Lilac uses a single procedural language for all aspects of document de¬ 
scription and supports fully integrated editing of that language. 

The system closest to Lilac in its goals is Vortex. 3 It is a complete implementa¬ 
tion of Tex built into a two-view framework. Because the Vortex team chose to 
build on an existing language, they were not free to optimize the language for 
quick response to page-view edits; as a result the system is much more oriented 
toward source-view editing. On the other hand, they inherited a well-honed for¬ 
matting system, with the result that Vortex is far more functionally complete than 
Lilac at its present stage of development. Because it is based on Tex, Lilac han¬ 
dles all aspects of document description with a single procedural language, but it 
does not deal explicitly in logical structure. 

Another interesting system is Quill. 4 Using the Structured Generalized Mark-up 
Language as a base language, it supports WYSIWYG editing not only for text but 
also for compound documents. It can handle text embedded in graphics embed¬ 
ded in text. A secondary view shows the structural hierarchy, sitting in a narrow 
column to the left of the text. It constantly shows how the current selection re¬ 
lates to the hierarchy. SGML is declarative and describes only structure; layout 
styles are described in a separate procedural language, REXX. Quill does not 
support integrated editing of the SGML and hence is not a full-fledged two-view 
system. 

The Grif 5 system also supports user-definable structure underlying a 
WYSIWYG editor. Using a document model in the spirit of ODA, it allows creation 
of arbitrary structure elements. A syntax may be specified to constrain the rela¬ 
tionships of structure elements (for example, a section may contain paragraphs 
but not other sections). Lilac would benefit from this feature. Grif uses a single 
declarative language for all aspects of document description. Layout style for 
each element type is specified by assigning values to a fixed set of attributes. 
This provides less power than the procedural languages used in Lilac, Vortex, 
and Quill. Grif is WYSIWYG only; there is no integrated view of the underlying 
language. 
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allow one to specify the prototypical empty 
instance of that class. Then the user could 
simply add “Chapter” to the menu instead 
of explicitly including code to specify 
“Chapter containing one Section contain¬ 
ing one Paragraph.” 

These extensions would be very useful, 
but they are just the tip of an iceberg. 
Programmable document structure really 
calls for a second kind of programmability: 
a programmable user interface. In addition 
to insertions and style attachments, all sorts 
of specialized searches, replacements, and 
transformations can be useful in the pres¬ 
ence of specialized text structures. A good 
example is an outline structure, where a 
useful operation is to promote subhead¬ 
ings, taking them from under their parent 
heading and setting them on the same level 
with it. This cannot be described in terms 
of simple hybrid commands; it is a tree 
transformation. To specify such things will 
require a programming language with built- 
in knowledge of the structure and data 
types of the syntax tree and operators for 
traversing it. 

Hierarchical selection works well when 
the structure is not very deep. When more 
than three clicks are used, though, it be¬ 
comes hard to count. A way to back down 
(unclick) is needed. It would be helpful to 
have a vertical selection area to the left of 
the text, as Bravo does; a click in this 
region would start selecting at the lowest 
level vertical element, thus skipping over 
three or four horizontal levels. 

Ambiguous levels of selection are an un¬ 
solved problem. The selections of “word” 
and Italic(“word”) look exactly the same in 
the page view, and there is no logical way to 
make them look different. Perhaps a graphi¬ 
cal overview of the structure, as in Quill, is 
the right answer. (For a look at Quill and 
other related systems, see the sidebar at left.) 

Is structure-based editing a good thing 
in this context, or would users prefer an 
interface less tied to structure? The Lilac 
experiment has produced a new editing 
context and has explored only one of many 
user interface alternatives, so I cannot an¬ 
swer conclusively. The Return key is clearly 
successful; hierarchical selection and ed¬ 
iting have uses, but they are sometimes 
constraining. At one time Lilac allowed 
selections to cut across structural bound¬ 
aries, though the only operation imple¬ 
mented on such selections was Cut. I found 
so little use for it that I took it out. Since then 
I have found one structure-crossing opera¬ 
tion that arises frequently enough to matter: 
merging two paragraphs while deleting some 
text around the boundary between them. 
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Others have mentioned the desirability of 
this operation. This probably indicates that 
paragraphs are not a very solid level of 
structure in the minds of authors. 

Language and semantics. A more 
flexible type system is desirable. In par¬ 
ticular, support for lists of lists, together 
with the ability to write functions that can 
enumerate and loop on their repeatable 
arguments, would allow general automatic 
layout of tables. This is not possible in the 
present system. 

A functional language is adequate for 
describing ordinary, linear text but not for 
describing the nonhierarchical features that 
occur in complex documents—for example, 
footnotes and end notes, figure and table 
numberings, floating figures, indexes, and 
cross-references. I firmly believe that with 
the addition of a few primitives with 
nonhierarchical semantics, these can all be 
handled within the Lilac language model. 
Although this area has been only partially 
explored, pilot implementations have been 
built. Indexes are generated offline; Lilac 
writes information to an external file, and 
a separate program processes it to generate 
the index as a separate Lilac source file. 
This process could be integrated into the 
editor, yielding a “generate index” com¬ 
mand that would probably take a few 
minutes. Tables of contents and lists of 
illustrations could be handled likewise. 

The other features can be handled in real 
or near-real time. Floating figures and foot¬ 
notes are handled as in Tex: The material is 
set aside in a special list, and the user- 
definable page model notifies Lilac to reserve 
space for this material when computing the 
page break. Figure and table numberings 
(not actually implemented) can be handled 
by defining special counter variables and 
giving them the property that each such 
variable maintains a linked list of all the 
references to it. When adding a new refer¬ 
ence changes the values of some old ones, 
appropriate points in the syntax tree are 
marked as modified, causing more than the 
usual recomputation to restore a consistent 
display list. The point is that these exceptions 
to pure functional semantics — relatively 
rare compared with ordinary text — can be 
handled adequately by special mechanisms. 
They add marginally to the computational 
cost, but they need not double it, and they 
certainly need not overthrow the entire 
functional model. Chamberlin 8 describes a 
neatly formulated algorithm for such up¬ 
dating in the Quill context. 

Today’s word processing users are de¬ 
manding multimedia — integrated editing 


of line graphics and images, and inclusion 
of foreign materials such as Postscript fig¬ 
ures. Such capabilities were intentionally 
left out of Lilac, but it can certainly be 
expanded to include them. Blind inclusion 
without editing is easy; the source view 
need only contain a reference to an exter¬ 
nal file. Lilac already does this for bit¬ 
mapped images and could easily do like¬ 
wise for Postscript figures on systems that 
have a screen-oriented Postscript imple¬ 
mentation. True integrated editing, how¬ 
ever, requires the design of two-view edi¬ 
tors for each data type handled and a method 
for smoothly integrating different source 
languages with syntaxes designed around 
different needs. The Quill project is also 
addressing this issue. 

Implementation. The incremental in¬ 
terpretation scheme, with a hash table 
storing partial display lists as intermediate 
values, proved quite successful. The 
avoidance of list copying means that nearly 
all the lists stored in the hash table are in 
fact part of the full-document display list, 
so the cost of storing this display list is paid 
only once. Even so, this tips the space- 
versus-speed trade-off heavily in favor of 
speed; there is an expansion of nearly 70 to 
1 between source text and the document in 
memory. This trade-off has its advantages: 
Lilac can flip through full pages of text at 
three pages per second or faster. However, 
it is not economical for real use. Faster 
machines will allow more efficient storage 
methods in which inactive parts of the 
display list are abbreviated or intelligently 
swapped out. 


F rom this experiment I conclude that 
the Lilac approach can indeed pro¬ 
vide the best of both the WYSIWYG 
editing and document compilation worlds, 
but not because of the pains taken to syn¬ 
chronize the two views. Rather, it is the 
combination of WYSIWYG editing with an 
underlying language accessible to the user 
that imparts the power. Language provides 
user-definable structure, which supports an 
entirely new level of convenience for spe¬ 
cialized tasks in WYSIWYG editing. Two- 
view editing is useful in that it provides an 
excellent environment for working in the 
language, but it is a secondary benefit and 
not a tool for constant use. 

The power of language imposes struc¬ 
tural constraints upon the WYSIWYG edit¬ 
ing process that are somewhat more com¬ 
plex than those found in ordinary 
WYSIWYG systems. The user interface 


can be designed to reflect these constraints 
or to conceal and work around them as 
much as possible. Lilac has explored the 
former approach, showing some benefits 
and some disadvantages. Future research 
must determine which approach is ultimate¬ 
ly better. ■ 
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A Novel Algorithm for 
Discrete-Event Simulation 


Asynchronous Distributed Discrete-Event Simulation 
Algorithm for Cyclic Circuits Using A Dataflow Network 


Erik DeBenedictis, Ncube Corporation 
Sumit Ghosh, Brown University 
Meng-Lin Yu, AT&T Bell Laboratories 


S imulation mimics a physical pro¬ 
cess to verify correctness, identify 
errors, and generate performance 
estimates before designers fabricate a pro¬ 
totype. Digital hardware designs, industri¬ 
al control circuits, and aircraft are usually 
simulated extensively. Time-based simu¬ 
lation techniques are efficient for pro¬ 
cesses whose activities are concentrated at 
regular time intervals that can be deter¬ 
mined a priori. 

Discrete-event simulation techniques 
apply where the activities are distributed 
irregularly in time, such as in digital 
hardware, queuing networks, and banking 
transactions. In discrete-event simulation, 
a simulation model representing an entity 
of the physical process remains idle except 
when excited by a stimulus external to it. In 
addition, only changes in a model’s response 
are propagated to other models connected 
to its output. 

Figure 1 shows an example digital 
hardware design. Each block A through G 
represents a design component and con¬ 
stitutes an entity of the physical process. 
The propagation delays of A, B, C, D, and 
F are 5,2,4,5, and 3 nanoseconds, respec- 
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I 1 

A synthesized dataflow 
network and a 
computed quantity 
“time of next event” 
guarantee correctness 
and freedom from 
deadlock. 


tively. Assuming an external stimulus at 
the inputs of A and B at t = 0 ns, the re¬ 
sponses from A and B may be asserted at 
{C} and { D,F } at t = 5 ns and t = 2 ns, 
respectively. A response from each of C, D, 
and F may in turn be asserted at the inputs 
of E and G at t = 9 ns, t = 7 ns, and t = 5 ns, 
respectively. The activities of the physical 
process are distributed irregularly in time, 

0018-9162/91/0600-0021$01.00 © 1991 IEEE 


so we formulate and efficiently simulate 
them through discrete-event simulation. 

A traditional algorithm to perform dis¬ 
crete-event simulation of digital hardware 
on a uniprocessor proceeds as follows: An 
event queue stores the events in increasing 
order of their assertion times, where the 
head of the queue refers to the event with 
the smallest assertion time. Initially the 
event queue is empty, and the external 
stimuli are asserted at the inputs of com¬ 
ponents A and B. The stimuli generate ac¬ 
tivity, namely the execution of A and B at 
t = 0 ns, shown in the event queue in Table 
1. At this stage, the algorithm examines the 
event queue and selects for execution events 
with the smallest time value, namely A and 
B at t = 0 ns. Assume that the execution of 
models A and B at t = 0 ns generates output 
transitions at t = 5 ns and t = 2 ns, respec¬ 
tively, that are asserted at the inputs of 
models C, D, and F, as shown in Figure 1. 
The new activities are expressed through 
events C at t = 5 ns, D at t = 2 ns, and F at 
f = 2 ns in the event queue in Table 1. Then 
the algorithm examines the event queue 
again, and selects the events with the 
smallest time — namely D at t = 2 ns and F 
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Figure 1. Discrete-event simulation of an example digital hardware design. 


Table 1. Event queue for the simula¬ 
tion in Figure 1. 


Time 

Components 

Activated 

f = 0 

A, B 

f = 2 

D, F 

t = 5 

C,G 

t = l 

E 

t = 9 

E 


at t = 2 ns — for execution. The process 
continues until the event queue is empty 
and the simulation is complete. Figure 2 
shows the process in a flowchart of the 
traditional uniprocessor-based discrete- 
event simulation algorithm. 

For many physical processes, a directed 
graph corresponding to the interactions 
among entities may assume the form of a 
cyclic circuit. For example, Figure 3 shows 
two cross-coupled Nand gates A and B 
constituting an RS latch (reset-set latch). 



Figure 2. Flowchart of an algorithm for discrete-event simulation of digital 
hardware. 


Assume propagation delays of 5 and 6 ns, 
respectively, for models A and B, and ini¬ 
tial logical values of 0 at t = 0 ns at the 
output ports p and q. Corresponding to the 
signal transition at the primary input port x 
at t = 0 ns, the algorithm executes A, which 
generates a new signal value at its output p 
at r = 0 + 5 = 5 ns. Similarly,corresponding 
to the transition at the primary input port y 
asserted simultaneously at t = 0 ns, B exe¬ 
cutes and produces a new signal value at its 
output port q at t = 0 + 6 = 6 ns. Corre¬ 
sponding to the new signal values at p and 
q, models A and B execute again. If the 
signals at each of ports x and y are un¬ 
changed, A and B execute again at t = 6 ns 
and t = 5 ns to produce output signal values 
at ports p and qatt = 6 + 5 = llns and t = 
5 + 6 = 11 ns, respectively. Consequently, 
for each execution of A and B, the output 
signal produced may, in the future, cause 
subsequent execution of A or B. 

Physical processes with cyclic circuits 
include all digital hardware designs with 
feedback, industrial control systems with 
negative feedback, oscillators, and sets of 
queuing networks interconnected in a closed 
loop. A well-known natural process with 
cyclic dependence is the food chain. 

An example shows how a uniprocessor- 
based discrete-event simulation system for 
a cyclic circuit works. The digital hard¬ 
ware design in Figure 4 consists of three 
interconnected oscillators comprising the 
sets of gates [A,B,C], {D,E,F), and 
{G,H,J}- The propagation delay for each 
gate A, B, and C is 100 ns; for each gate D, 
E, and F, 3 ns; and for each gate G, H, and 
J, 5 ns. Initially, the logical value at the 
primary input of A is 0 and the event queue 
is empty. Corresponding to a signal transi¬ 
tion 0 to 1 at the primary input of A at t = 0 
ns, A is activated, and the algorithm includes 
the event in the event list in Table 2. The 
algorithm executes component A to pro¬ 
duce a l-to-0 transition at its output port at 
t = 100 ns. As a result, the event queue now 
contains the event at B at t = 100 ns. When 
component B executes at / = 100 ns, it 
generates an output transition at its output 
port at t = 200 ns. The event queue now 
contains an event at C at t = 200 ns. When 
C executes at t = 200 ns, it generates an 
output transition at its output port at f = 300 

The event queue now contains three 
events: A, D, and G, each at t = 300 ns. 
Because the primary input of A is defined 
up to t = 1,000 ns, A executes again at t = 
300 ns and generates an output transition at 
t = 400 ns, which causes an event at t = 400 
ns in the event queue. Corresponding to the 
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Figure 4. Discrete-event simulation of a cyclic circuit. 
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Figure 3. Cross-coupled Nand latch. 


executions of D and G, output transitions 
are generated at the output ports at t = 303 
ns and t = 305 ns, respectively. The event 
queue now contains three events— E, H, and 
B — to be executed at t equals 303, 305, 
and 400 ns, respectively. The simulation 
continues and terminates when either the 
event queue is empty or the simulation 
time exceeds the maximum simulation time. 

The event queue in Table 2 shows that 
for the simulation time t = 300 ns, the al¬ 
gorithm can execute the set of components 
{ A,D,G } simultaneously. But in a unipro¬ 
cessor system, the components must be 
executed sequentially. A parallel-proces¬ 
sor system could execute the components 
in each of the sets concurrently, possibly 
speeding the simulation. A parallel-pro¬ 
cessor system might also speed simulation 
of acyclic circuits. 

No reported parallel-processor algorithm 
for circuits in which the process interactions 
form a cyclic graph offers a solution with 
acceptable performance, freedom from 
deadlock, and provable correctness. In this 
article, we propose a method that uses a 
dataflow network synthesized on the basis 
of the connectivity of the circuit compo¬ 
nents. Our algorithm computes a quantity 
“time of next event” for each component, 
which permits the corresponding model to 
execute asynchronously as far ahead in 
simulation time as possible. The network 
ensures that a simulation process executing 
in a distributed processing environment 
will not deadlock. 

Distributed discrete- 
event simulation 

We studied distributed techniques be¬ 
cause of their potential to simultaneously 
execute multiple entities of a complex 
discrete-event simulation and thereby speed 
the simulation. The synchronous, rollback. 


and asynchronous approaches are current¬ 
ly the three principal distributed techniques. 

Synchronous mechanism. In the syn¬ 
chronous approach, 1 a processor designat¬ 
ed as a centralized controller allocates all 
other entities to the processors of the par¬ 
allel-processor system and initiates their 
executions. The controller also resynchro¬ 
nizes all processors at the end of every 
activity. An example of a system imple¬ 
menting the synchronous approach is the 
Zycad hardware accelerator machine, which 
uses the synchronous algorithm for gate- 
level logic simulation. 

The synchronous approach permits the 
concurrent execution of entities corre¬ 
sponding to two or more events at the 
simulation time given by t = r„ but it has 
some limitations. The processors must re¬ 
synchronize at the end of each activity, 
even in the absence of data dependency, 
and message communication may not be 
complete at the end of an activity. 

A synchronous distributed simulation of 
the example circuit in Figure 4 illustrates 
some of these problems. Assume that the 
components A through J are allocated to 
nine processors (one component per pro¬ 
cessor). A 10th processor of the parallel- 
processor system is the centralized con¬ 
troller that maintains the global event queue. 
Corresponding to the signal transitions at 
the primary input ports of A, the event queue 
contains a single entry: A at t = 0 ns. The 
controller initiates the execution of A. 
Except for the processor that contains the 
component A, the other eight processors 
are idle. Execution of A generates an out¬ 
put transition that causes an entry in the 
event queue: B at t = 100 ns. Then the 
controller initiates the execution of B, and 
the process continues as for a uniprocessor, 
with one exception. Unlike in a uniprocessor 
system, where the components A, D, and G 


Table 2. Event queue for the simula¬ 
tion in Figure 4. 


Time 

Components 

Activated 

t = 0 

A 

t= 100 

B 

t = 200 

C 

t = 300 

A, D, G 

t = 303 

E 

t = 305 

H 

t = 400 

B 


must execute sequentially at t = 300 ns, in 
the synchronous approach A, D , and G can 
execute concurrently in three processors. 
However, all three must execute completely 
before the algorithm simulates the subse¬ 
quent event Eatt = 303 ns, followed by H 
at t = 305 ns. Components E and H are not 
data dependent, but the synchronous al¬ 
gorithm fails to achieve their simultaneous 
execution. 

Rollback mechanism. The rollback 
mechanism 2 saves the state of the entire 
system periodically so the simulation system 
can roll back to its previous state if an error 
results from messages processed out of 
order. If a model has no information about 
a signal at an input port, it assumes that the 
signal value has remained unchanged and 
propagates to subsequent models the results 
of execution based on that assumption. If 
the component receives a subsequent 
message that contradicts its previous as¬ 
sumption, it propagates new results to 
subsequent models in the form of an¬ 
timessages. Limitations of the rollback 
mechanism include the significant storage 
required to periodically save the state of 
the entire simulation and the uncertainty 
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Figure 5. Asynchronous simulation of 
a cyclic circuit. 


resulting from propagating a combination 
of messages and antimessages throughout 
the simulation system. 

Asynchronous mechanism. The asyn¬ 
chronous discrete-event simulation mech¬ 
anism 34 permits every simulation model to 
execute independently where there is no 
explicit data dependency, giving the po¬ 
tential for maximum parallelism. The ex¬ 
ample circuit shown in Figure 4 permits the 
following concurrent, independent execu¬ 
tions: Component B may execute at t = 400 
ns following execution of A at f = 300 ns, E 
at t = 303 ns following Da.it = 300 ns, and 
H at t = 305 ns following G at t = 300 ns. 

The next section reviews previous ap¬ 
proaches to asynchronous discrete-event 
simulation of cyclic circuits. Then, we 
present our new approach and compare it 
with the previous approaches. We also 
comment on the proof of our algorithm’s 
correctness, implementation issues, and our 
algorithm’s performance. 

Asynchronous 
simulation of cyclic 
circuits 

The asynchronous approach permits 
every simulation model to execute inde¬ 
pendently in the absence of data depen¬ 
dency. Consequently, its success with a 
simulation system is a function of the 
computational requirement of the models 
and the degree of data dependency between 
the models. For a set of entities constitut¬ 
ing a cyclic circuit, the output generated as 
a consequence of an entity’s execution 
may influence its input at a later time. 
Consequently, compared with acyclic cir¬ 
cuits, cyclic circuits require more syn¬ 
chronization, which may diminish the ef¬ 
fectiveness of the asynchronous approach. 

Figure 5 shows another serious difficulty 
in the asynchronous approach to cyclic 
circuits. The input ports of model A are pi 
and p2, and the input port of B is p3. The 
output of model B connects to p2 of A, and 
the output of A connects to p3 of B. The 


propagation delays of A and B are d, and d 2 , 
respectively. Assume distributed asyn¬ 
chronous discrete-event simulation of a 
design where A and B are associated with 
two distinct processors of a parallel pro¬ 
cessor. Simulation has run to termination 
when all externally supplied usable signal 
transitions have been used to generate out¬ 
put transitions. 

Assume also that initial logical value 0 is 
associated with ports p3 and p2 at t = 0 ns. 
For a given signal transition 0 to 1 at port 
pi of A at t = 0 ns, the algorithm executes 
A. Assume that the logical value of 1 at pi 
persists up to t = Tns, where T is very large. 
If the execution of A generates a transition 
at its output port at t = 0 + d, = d u the 
transition is propagated to B, causing B to 
be scheduled for execution at t = d x . If the 
execution of B at t = d x generates a transi¬ 
tion at its output port at t = d x + d 2 , the 
transition is propagated to port p2 of A. As 
a result, A may execute again, and the 
process will continue as long as the algo¬ 
rithm can correctly schedule models A and 
B for execution. 

If the execution of B at t = d x does not 
generate a signal transition at its output 
port, no message is sent from 5 to A. 
Consequently, model A is unaware that the 
port p2 is at logical 0 up to t = d x + d 2 and 
is unable to execute beyond t = 0 ns. The 
signal value of 1 at port pi persists up to t 
= T ns and, therefore, the simulation should 
execute until the transition t = T ns. But A 
cannot execute without messages from B, 
and B cannot execute without messages 
from A. This constitutes a deadlock, caused 
by the absence of information at an input 
port of a model and the lack of global 
knowledge that the signal value at that port 
has remained unchanged. 

A method called deadlock recovery 5 
addresses the difficulty by letting the entire 
simulation system execute until it deadlocks, 
that is, until none of the entities is sched¬ 
uled for execution and the overall simula¬ 
tion has progressed only partially. A dis¬ 
tributed deadlock-detection algorithm 15 
detects the deadlock state. The algorithm 
synchronously computes the minimum (say 
X ) of all outstanding event times and the 
assertion times of external signals for ev¬ 
ery entity. Then, it lets every entity execute 
up to t = X ns. 

For the example circuit in Figure 5, 
deadlock recovery lets the entire simulation 
system constituted by entities A and B 
execute until it results in a deadlock. Assume 
that models A and B execute at t = 0 ns and 
t = d x ns, respectively, and that the execu¬ 
tion of B does not generate a transition at its 


output. At the instant that the deadlock- 
detection algorithm detects the deadlock, 
component B has no outstanding events to 
execute, nor does it connect to an external 
input signal. Also, component A has no 
outstanding event to be executed, but the 
external signal at port pi is defined at t = T 
ns. Consequently, the algorithm computes 
the minimum X to be T ns and lets models 
A and B execute on the assumption that the 
signals at p2 and p3 have remained un¬ 
changed up to t = T ns. 

The deadlock-recovery scheme has 
limitations. The scheme fails for systems 
with both cyclic and acyclic circuits, that 
is, systems where not all entities may result 
in a deadlock. Moreover, issues of perfor¬ 
mance and correctness are difficult to re¬ 
solve because entities execute into deadlock. 
Implementation 6 of the deadlock recovery 
scheme has shown that the simulation runs 
from one deadlock to the subsequent 
deadlock state and that the algorithm per¬ 
formance is nonlinear with respect to in¬ 
creasing problem size. 

A second way 3 to handle deadlock is to 
identify and mark all entities of a simula¬ 
tion system that constitute cyclic subcircuits 
and set their execution modes to exception 
mode. In exception mode, an output signal 
generated when an entity executes is 
propagated to subsequent entities even when 
the signal is unchanged from its previous 
value. When an entity receives a message 
at an input port that corresponds to an 
unchanged signal value, the algorithm 
schedules the entity for execution exactly 
as for a message corresponding to a signal 
transition. 

In simulation of the example design in 
Figure 5, first model A executes and then B 
executes. The execution of B generates no 
transition at its output. But the system is 
operating in exception mode, so a message 
corresponding to the unchanged signal value 
at p2 at t = d x + d 2 is propagated to A. Then, 
entity A executes again, generating an un¬ 
changed signal at its output at f = 2d, + d 2 , 
which is subsequently propagated to B. The 
process continues until the external signal 
at pi for t = T ns is used and the output 
signals at ports p2 and p3 are appropriately 
determined. 

This approach 3 guarantees absence of 
deadlock in a system with cyclic circles of 
any degree of complexity. Its principal 
limitation is its inefficiency, particularly 
when an external signal of a cyclic design 
that is nonoscillatory remains unchanged 
for a long time. For instance, assume that 
the example circuit in Figure 5 is non¬ 
oscillatory. Messages corresponding to 
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unchanged signal values will propagate 
from A to B and from B to A at intervals of 
(d, + d 2 ) ns. The total number of iterations 
around the cycle until simulation termi¬ 
nates is approximately (1,000/(d,+<i 2 )). The 
total CPU time required for simulation is 
proportional to the number of iterations, so 
when the ratio (l,000/(d,+d 2 )) is large, ef¬ 
ficiency is low. 

A new approach 

We propose a new approach to avoid 
deadlock called Yaddes, which stands for 
“yet another asynchronous distributed 
discrete-event simulation algorithm.” For 
a system such as a digital design, we identify 
subcircuits that constitute cyclic directed 
graphs and simulate only the entities of 
such subcircuits using the new approach. 
We simulate system entities that constitute 
acyclic graphs using the exception-mode 
approach 3 described in the previous section. 
In this article, we present the Yaddes ap¬ 
proach for use with digital hardware, but it 
applies equally well to queuing networks 
and banking transactions. 

Overview. Feedback loops are the 
principal cause of deadlock in traditional 
asynchronous distributed discrete-event 
simulation systems. The simulation envi¬ 
ronment represented through models con¬ 
nected by feedback loops cannot accurately 
decide the precise execution of events. To 
enable circuit execution in a deadlock-free 
environment, the Yaddes approach uses a 
synthesis of an acyclic circuit of 
pseudocomponents based on the original 
simulation circuit. Unlike simulation 
models that require substantial computa¬ 
tional power, pseudocomponents are purely 
mathematical entities that evaluate func¬ 
tions. A pseudocomponent inherits only 
the input and output ports of the corre¬ 
sponding simulation model. 

To preserve the algorithm’s asynchro¬ 
nous and concurrent nature, each 
pseudocomponent represents a decision¬ 
making entity whose sole function is to 
determine when the corresponding simu¬ 
lation model can correctly execute an input 
event. An event refers to a signal transition 
at an input port. Yaddes requires that each 
pseudocomponent compute a quantity “time 
of next event” ( W) at its output port. To do 
this, a pseudocomponent applies a minimum 
operator over the W values at its input ports 
and the simulation time of the event of the 
corresponding simulation model. Thus, the 
pseudocomponent must access the simula¬ 



Figure 6. Reducing a cyclic directed graph (a) to an acyclic directed graph (b). 


tion time of the event from the related 
simulation model. This quantity is a mea¬ 
sure of the time at which the next event is 
expected at that path. Furthermore, the 
algorithm can use this quantity to decide 
whether a model can safely execute an 
event. The minimum function shows the 
conservative nature of the Yaddes algo¬ 
rithm. 

Corresponding to each of the inputs of 
the acyclic circuit that represent the primary 
inputs, the algorithm defines the W value 
as equal to the assertion time of the most 
recent transition. The remaining inputs of 
the acyclic circuit are unconnected because 
they are not influenced by any events in the 
circuit. Their VV values are assumed to be 
permanently held at a very large number 
expressed as °° so they cannot influence the 
W computations of the pseudocomponents. 

A limitation of the synthesized acyclic 
circuit is the lack of connectivity between 
the pseudocomponents of the respective 
feedback loops that may be required in the 
simulation circuit. For a given feedback 
loop, the W value at the output of the 
leftmost pseudocomponent does not reflect 
the simulation times of the events associ¬ 
ated with other simulation models in the 
same loop or those of other models that 
may influence the computation. As aresult, 
the computed W value may be inaccurate. 
In fact, the value will probably be “opti¬ 
mistic” and imply a value greater than the 
true value, for the following reason. Because 
the algorithm uses the minimum operator, 
W' values it associates with other models 
imply only a lower value in the computa¬ 
tion of the W' value for a pseudocompo¬ 
nent. 

To address this limitation, we synthe¬ 
size a second identical copy of the acyclic 
circuit. To distinguish between them, we 
call the first and second acyclic circuits 
primed and unprimed, respectively, and 
express the quantity “time of next event” 
as W for the unprimed circuit. Each output 
of the primed circuit connects to each input 
of the unprimed circuit through a minimum 
operator. A crossbar switch expresses the 
dependency between the feedback loops in 


this interconnection network. If the activ¬ 
ities of a feedback loop do not affect those 
of another loop, the corresponding link in 
the switch is considered nonexistent; oth¬ 
erwise, a link exists. An existent link has a 
weight equal to the computed propagation 
delay from the output of the primed 
pseudocomponent X' to the input of the 
unprimed pseudocomponent Y. Although 
the maximum capacity of the switch is N x 
N, the actual size is defined by the circuit. 
(We discuss the role of the outputs of the 
unprimed circuit in a later section.) The W 
values computed by the pseudocomponents 
of the unprimed circuit correctly include 
the simulation times of all appropriate events 
in the entire circuit. The algorithm uses 
these values to accurately determine when 
an event can be executed by a model. We 
call the primed and unprimed circuits and 
the switch collectively the dataflow network 
for the circuit. 

The optimistic nature of the evaluation 
process in the primed circuit acts as a 
window into future events. These future 
events are presented to the unprimed circuit, 
whose conservative characteristics guar¬ 
antee simulation accuracy. The primary 
cause of deadlock — the cyclic data de¬ 
pendence in the feedback loops — is re¬ 
solved by a dataflow network that lacks 
any cyclic dependence between its con¬ 
stituent pseudocomponents. 

Yaddes algorithm. For a circuit con¬ 
taining feedback loops, first we identify a 
feedback arc set 7 S given by S = {£,, £ 2 , 
£„} of a directed graph corresponding to a 
digital design. This lets us render the graph 
as acyclic after we remove all the edges £, 
through E n . The correctness of the approach 
is not contingent on identifying the mini¬ 
mal feedback arc set, which is difficult and 
time consuming to do. However, identify¬ 
ing the minimal feedback arc set may im¬ 
prove performance. 8 

For each £, V i e {1, 2, ..., n} in the 
original directed graph, we reconstruct a 
new acyclic directed graph by replacing £, 
with two unconnected edges £/" and £,"“'. 
Figure 6a shows a cyclic circuit consisting 
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Figure 7. Dataflow network constructed for the cyclic circuit in Figure 6a. 
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Figure 8. A digital design with cyclic subcircuits. 



of a two-input And gate A whose output 
connects through edge £ 2 to the input of the 
inverter B. The output of the inverter B 
connects through edge E , to an input of A. 
The other input port of A is edge £ 3 . 

Assume that the feedback arc set for the 
circuit is given by 5 = {£,}. We rendered 
the graph in Figure 6b acyclic by removing 
E , and replacing it with £,'" and as¬ 


sociated with the input of A and the output 
of B, respectively. 

Next, we synthesized a dataflow net¬ 
work by connecting two identical copies of 
the acyclic circuit through a crossbar switch. 
The two acyclic circuits to the left of the 
crossbar switch are primed and to the right, 
unprimed. The entities in the dataflow net¬ 
work corresponding to the primed and 


unprimed circuits are the primed (A') and 
unprimed (X) pseudocomponents, where X 
refers to the corresponding simulation 
model. Every input port of a pseudocom¬ 
ponent X' that has a label of the form £/" is 
permanently held at a very large number 
represented by °°. An output port of every 
X' that has a label of the form £/“' is linked 
to every input port of any pseudocompo¬ 
nent Y in the unprimed circuit that has a 
label of the form E k ln . 

The collection of links constitutes the 
crossbar switch. For a feedback arc set of 
size A, the maximum capacity of the switch 
is given by N 2 . Where the activities of the 
simulation models of a feedback loop may 
affect those of another loop, the corre¬ 
sponding link in the switch exists. Other¬ 
wise, it is nonexistent. A link connecting 
the output port £,““ of a pseudocomponent 
X' in the primed circuit to an input port £/" 
of a component Y in the unprimed circuit 
merely propagates the W x ' values from X' 
to y, delayed by the weight associated with 
the link. Figure 7 shows the dataflow net¬ 
work for the cyclic graph in Figure 6a. 

In Figure 7, the pseudocomponents A' 
and B' constitute the primed circuit where 
the input port £,“ of A' is permanently held 
at A' and B' correspond to the And and 
inverter gates in the simulation circuit. 
Pseudocomponents A and B constitute the 
unprimed acyclic circuit. The output port 
£,“' of B' is connected via the crossbar 
switch to the input port of £/” of A because 
the activities of models A and B may affect 
each other. The feedback arc set has a size 
of 1, so the size of the crossbar switch is l 2 
= 1. The first input ports of both A and A' 
connect to the external path £ 3 . Associated 
with £ 3 are the externally applied signal 
transitions. Conceptually, we can include 
these transitions in the event list of model 
A — that is, the list of outstanding input 
transitions of A — and hold £ 3 at °°. Fur¬ 
thermore, conceptually the output port E i ° m 
of B is unconnected. However, in the cur¬ 
rent implementation of Yaddes the output 
of B is connected to a special entity “P” 
signifying that it is the rightmost boundary 
of the dataflow network. We say more 
about this connection later in this section. 

Figure 8 shows three cyclic subcircuits. 
Figure 9 shows the dataflow network cor¬ 
responding to their digital design. The dig¬ 
ital design in Figure 8 consists of three 
cyclic subcircuits X,, K 2 , and X 3 constituted 
by the sets of components {A,fi,C}, {£>,£}, 
and { F,G,H} respectively. X, and X 3 are 
oscillators with time periods of 30,000 and 
3,000 ns, respectively, and K 2 is nonoscil- 
latory. The oscillatory transitions of X, are 
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generated corresponding to a logical value 
of 1 at the input port of model A of A",, and 
the transitions drive the models in K 2 and 
X 3 . The feedback arc set for the simulation 
circuit is { m,n,p }. Figure 9 shows the con¬ 
sequent acyclic subcircuits derived from 
K u K 2 , and X 3 and the dataflow network. 
The input ports m in , m in , n‘\ m‘", and p in of 
the pseudocomponents A',D', and F' result 
from removing the edges m,n, and p of the 
original design. The input ports are all 
permanently held at <*>. The output port m M 
of component C connects to the input ports 
m‘" of each of the pseudocomponents A, D, 
and F, reflecting the fact that the activities 
of the models of Xj can influence those of 
both K 2 and X 3 . The output port p°“' of H' 
connects only to the input port p‘" of F, 
reflecting the fact that the activity of X 3 
influences neither X, nor K 2 . Similarly, the 
output port n oul of E' connects only to the 
input port n‘" of D. Consequently, the 
crossbar switch has only five links: C' to A, 
C' to D, C' to F, E' to D, and H' to F. 

Associated with the output port of each 
pseudocomponent X' e {A', B ',..., H'} is a 
mathematical quantity “time of next event” 
represented by the symbol W x . (See the 
sidebar for mathematical definitions of W/, 
U x , and W*.) Intuitively, W x is the pre¬ 
dicted time of the next event at the output 
of model X. The algorithm computes it from 
the W values at the input ports of X' and the 
simulation time of the event of model X. The 
computation of W x is triggered by any 
change in the values of its arguments. Any 
computed W x is propagated to other 
pseudocomponents connected to its fanout 
when it differs from the previous value. 
Moreover, the propagation is like a chain 
reaction: Subsequent components that in¬ 
tercept the W values are also executed, and 
any changes in their output values are fur¬ 
ther propagated. The chain reaction ter¬ 
minates either when no new W values are 
generated or when it encounters the right¬ 
most component of the network. A process 
of acknowledgments detects the termina- 

The W values are optimistic. In the 
dataflow network in Figure 9, given that 
the second input port of A' is permanently 
held at °°, the value of W A is defined only 
by the simulation time of the transition at 
the first input port of A'. We expect the value 
of W A to reflect the simulation time of the 
next event, yet it fails to take into account 
other events at B' and C possibly with 
lower simulation times than that at A'. 
Similarly, the computation of W D ' fails to 
consider events at E' and even A', B', and 
C, because the activities of the feedback 


Formal definitions 


Here are formal mathematical definitions of the quantities U x , W/, and W x that 
we describe intuitively in our presentation of the Yaddes algorithm. 

Definition of U x . We associate with every simulation model X a collection of 
events — that is, transitions received at its input ports propagated from other 
models as messages. The algorithm orders the events in increasing order of their 
simulation times in an event list, and ultimately they may be executed by the 
model X. At any instant, U x is equal to the simulation time of the event at the 
head of the list — the event with the smallest value of simulation time. When the 
list is empty, the value of U x is considered equal to «. Initially, every U x V X in 
the simulation circuit is set to «>. For the component A in the example circuit in 
Figure 8, assume signal transitions 0 to 1 at f = 0 ns and 1 to 0 at f = 100,000 ns 
at the external input of A. Also assume that other input ports of A receive no 
messages until then. Then U A refers to the transition 0 to 1 at t = 0 ns, and 
U A = 0. . 

Definition of W x . A mathematical quantity W x is associated with the output 
port of every primed pseudocomponent X in the dataflow network. We compute 
it through the function W x = minimum (U x + d, W,' + d, ..., W„' + d) where W/, 

.... W„' refer to the W values at the input ports 1. n of X, and d refers to the 

propagation delay of model X. W x usually is an optimistic and inaccurate mea¬ 
sure of the simulation time when the next event will arrive at the output of model 
X. Initially, the algorithm sets every W x V Xto 0, indicating that they are not yet 
influenced by any event. 

Definition of W x . A mathematical quantity W x is associated with the output 
port of every unprimed pseudocomponent X in the dataflow network. Formally, 

W x is computed through the function W x = minimum (U x + d, W, + d,.... W„ + d), 

where W,. W n refer to the W (or W') values at the input ports 1,.... n of X, and 

d refers to the propagation delay of model X. In some cases, as with the 
unprimed component A in Figure 9, a W value (in this case W c ') may be in¬ 
volved in the computation of a W value (in this case W A ). W x represents an accu¬ 
rate measure of the simulation time when the next event will arrive at the output 
of model X. To preserve the correctness of the simulation — the proper order of 
event execution — no message with a simulation time given by t < W x can be 
sent by model X at its output port following the possible propagation of a mes¬ 
sage with simulation time / = W x . Initially, the algorithm sets every W x V X to 0, 
indicating that they are not yet influenced by any event. We consider the simula¬ 
tion to be complete when W x and U x VXare identical to °°. 


loop K , may affect those of K 2 . Since the W 
computation involves the minimum 
operator, failure to consider other events 
may yield values larger than the correct 
values. Moreover, these values are opti¬ 
mistic because they allude to events even 
when there may be other events with pos¬ 
sibly lower simulation times. 

Associated with each of the pseudocom¬ 
ponents Y 6 {A, B ,.... H] of the unprimed 
circuit is a similar mathematical quantity 
represented by W r . The W values share the 
principles of computation and propagation 
of W values. However, in contrast to the 
W values, the W Y values are accurate. 
Therefore, the algorithm uses them to de¬ 


termine whether a simulation model event 
can be executed. Conceptually, the W values 
are accessed by the corresponding simula¬ 
tion models in the simulation circuit. 

As with any distributed simulator, the 
algorithm stores the signal transitions re¬ 
ceived at the inputs of a simulation model 
in an event list for that model. The head of 
the list refers to the transition with the 
smallest value of simulation time. We also 
call this the event of the model, and repre¬ 
sent the value of its simulation as U x . In the 
Yaddes approach, every event of a model 
canbeaccessedbythe corresponding primed 
and unprimed pseudocomponents. 

The two major elements of the Yaddes 
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read in events at input ports — from external ports or other components 

update event queue and order events according to time 

if (new event alters U value) { 
initiate pseudocomponents X and X' 
wait until done signal received from X and X' 
send acknowledgment to the sender of the event 

} 

else if (new event does not alter the U value) { 
send acknowledgment to the sender of the event 

} 

read W values at every input port of the simulation model X and compute the 
minimum K 

if (K value exceeds U value) { 
execute simulation model and generate output signal 
if (output signal does not differ from previous value) { 
remove U value and update event queue to reflect new U value 
if (event queue is empty) set U to infinity 
initiate X and X' to update W and VV' values 
wait until done signals from X and X' are received 

} 

else if (output signal differs from previous value) ( 
send output event to all models in the fanout 
wait for acknowledgment from each one of them 
remove U value and update event queue to reflect new U value 
if (event queue is empty) set U to infinity 
initiate X and X' to update W and W values 
wait until done signals from X and X’ are received 

} 

} 


Figure 10. Operations of a simulation model X. 


read in command from simulation model X, new W' value from left, and 
acknowledgments from right 

if (command from model X is read) { 
compute W 

if (W value remains unaltered) { 
send done signal back to model X 

} 

else if (W' computes to a new value) { 
propagate new W value and expect acknowledgment from the receivers 
upon receiving acknowledgment, send done signal to simulation model X 

) 

} 

else if (new W value is read) { 
compute the output W' value 

if (W' value is unchanged) send acknowledgment back to sender 
else if ( W' computes to a new value) { 
propagate new W' value and expect acknowledgment from the receivers 
upon receiving acknowledgment, send acknowledgment to the sender on the 
left 

} 

} 

else if (acknowledgment received from the right) { 
if (acknowledgment is for itself) send done signal to simulation model X 
else if (acknowledgment is not for itself) relay it toward the original requestor 


Figure 11. Operations of a pseudocomponent X' or X. 


simulation environment are the simulation 
circuit and the dataflow network. The sim¬ 
ulation circuit consists of executable models 
corresponding to each component of the 
circuit, and the flow of signals between the 
models is represented by messages over 
communication protocols. The models ex¬ 
ecute signal transitions received at the in¬ 
put ports, and any output transitions gener¬ 
ated as a consequence of execution are 
propagated to other models connected to 
the output port. However, the constituents 
of the dataflow network generate decisions 
about the precise execution of an event. 
The primed and unprimed pseudocompo¬ 
nents execute concurrently and asynchro¬ 
nously with respect to one another and the 
simulation models. (In the current imple¬ 
mentation of Yaddes, they are executed 
round-robin by a processor.) The execution 
of a pseudocomponent is initiated either by 
the corresponding model or by the propa¬ 
gation of a new W (or W') value at an input 
port by other pseudocomponents. 

Because Yaddes is a distributed approach, 
the subalgorithms describing the opera¬ 
tions of a simulation model, a primed 
pseudocomponent, and an unprimed com¬ 
ponent apply equally to all other respective 
entities in the system. Assume that a signal 
transition is asserted at an input port of 
simulation model X either by another sim¬ 
ulation model or from the external world. 
When the algorithm incorporates this event 
in the event queue of X, the event either 
alters U x or leaves it unchanged. When U x 
is altered as a consequence of the incoming 
signal transition, model X is initiated for 
execution. The simulation model X initiates 
the corresponding pseudocomponents X and 
X' of the dataflow network for execution 
and suspends the execution of the event 
until the pseudocomponent executions are 
completed. X' evaluates W x , and if its val¬ 
ue has not changed from its previous value, 
X' propagates a message to the model X 
signifying that X' has completed its execu¬ 
tion. If the new value of W x is a change 
from its previous value, X' initiates the chain 
reaction described earlier: It propagates 
the W x value to other pseudocomponents 
connected to its output port. When a subse¬ 
quent pseudocomponent executes as a 
consequence of a new W' or W value as¬ 
serted at an input port and generates a new 
W ox W value at its output port, it propa¬ 
gates the new output value to other 
pseudocomponents on the right through 
the crossbar switch if necessary. 

Computation and propagation of new W 
or W values at the output of pseudocompo¬ 
nents continue until either no new W or W' 
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Figure 12. Example design for asynchronous distributed discrete-event simula¬ 
tion. 


values are generated or the rightmost 
boundary of the dataflow network is en¬ 
countered. Then the pseudocomponents 
where the chain reaction terminates ini¬ 
tiate acknowledgments and propagate them 
in the reverse direction. When other 
pseudocomponents that participated in the 
chain reaction receive acknowledgments, 
they take turns propagating them in the 
reverse direction. Eventually, X' (the pri¬ 
mary initiator of the chain reaction) inter¬ 
cepts the acknowledgment and realizes that 
the process of updating W' or W values in 
the dataflow network caused by a change 
in W x has completed. It then sends a mes¬ 
sage to model X signifying that its execu¬ 
tion is complete. 

A pseudocomponent can be initiated even 
by new W or W values asserted at its input 
port by other such components. The behav¬ 
ior of the pseudocomponent X following its 
initiation by model X is identical to that of 
X\ except that the chain reaction is confined 
to only the unprimed acyclic network. 
Conceptually, pseudocomponents X and X' 
can be initiated concurrently by the simu¬ 
lation model X. Also, multiple simulation 
models can be executed simultaneously as 
a result of signal transitions at their input 
ports. Consequently, the computations of 
the W and W values initiated by multiple 
pseudocomponents may overlap. Consis¬ 
tency and correctness are guaranteed be¬ 
cause the computations involve a minimum 
operator and because the W value can 
never decrease. 9 

When both components X and X' have 
completed execution or when the signal 
transition asserted at an input port of model 
X does not alter its U value, the simulation 
model X sends an acknowledgment to the 
model that propagated the signal transi¬ 
tion. If the signal transition was asserted 
externally, the acknowledgment indicates 
that the transition is being processed and 
requires the external world to send the 
subsequent signal transition to that primary 
input port. 

Next, the simulation model X accesses the 
W or W values associated with each of the 
input ports of the corresponding unprimed 
pseudocomponent and computes their 
minimum K x . When U x *°° — that is, an 
event exists at X and K x exceeds U x — the 
model can execute the event correspond¬ 
ing to U x . When no new transitions are 
generated at the output port of model X 
following its execution, the algorithm de¬ 
letes the event corresponding to U x from the 
event queue and a new U x reflects the time 
of the new event at the head of the event 
queue. When the event list of model X is 


empty, U x is set to If a transition is 
generated at an output port as a conse¬ 
quence of execution of model X, it is 
propagated by X to other models that are 
connected to the output of X. Model X 
suspends further execution until it receives 
acknowledgments from each of the recip¬ 
ients. Then the algorithm removes U x from 
the event queue and a new U x is associated 
with the event at the head of the queue. The 
value of U is set to when the number of 
outstanding transitions at X is zero. The 
simulation model X then again initiates the 
pseudocomponents X and X' for execution 
and suspends further activity until the 
pseudocomponents have completed exe¬ 
cution. The process continues until all us¬ 
able external signal transitions at the pri¬ 
mary input ports are used to generate output 
transitions. 

Figures 10 and 11 present the precise 
functionalities of a representative simula¬ 
tion model and a corresponding 
pseudocomponent. The description in Fig¬ 
ure 11 applies to both primed and unprimed 
components. 

An example. Figure 12 shows how our 
asynchronous distributed discrete-event 
simulation algorithm works for an exam¬ 
ple design. In Figure 12, a Nand gate con¬ 
nects to an inverter through a feedback 
loop. The output of the Nand gate A con¬ 
nects to the input of the inverter B and the 
output of B connects to the second input 
port of A. The other input port of A is pri¬ 
mary. A transition from high to low is 
asserted at t = 0 ns, followed by a low-to- 
high transition at t = 1,000 ns. The propa¬ 
gation delays of both A and B are 5 ns. 

We assume that the initial values at the 
outputs of A and B are 0 and 1, respective¬ 
ly. For the given signal transition at the 
primary input of gate A, the outputs of both 
A and B change and remain stable thereaf¬ 
ter. When simulated by a conventional 
asynchronous distributed discrete-event 
simulation algorithm, 1 gates A and B will 
deadlock as the signal values at the output 
ports do not change. 


The feedback arc set for the circuit in 
Figure 12 is the arc from the output of B to 
the second input of A, and the dataflow 
network is constructed appropriately. 
Figures 13a through 13h are snapshots of 
the network as simulation progresses. The 
first input ports of both pseudocompo¬ 
nents A and A' are connected to T, and the 
second input port of A' is held at °°. The 
output of B' connects to the second input 
of A through the crossbar switch. 

The rectangular box above each 
pseudocomponent represents the event 
queue and contains the assertion time and 
transitions for every event. The U value (the 
right-hand entry in the box) for a 
pseudocomponent is the assertion time of 
the event at the head of the queue. For 
each of the snapshots, the figure also shows 
the computations of the W and W values 
at the output of components. Associated 
with each unprimed pseudocomponent in 
Figures 13a through 13h is the computa¬ 
tion of K, which is equal to the minimum 
of the W or W' values at the input ports of 
the component. The simulation models 
compute the K values, which are given in 
the figure to demarcate the states of the 
simulation models as simulation 
progresses. 

Figure 13a describes the initial state 
where U A =U B = «‘ and W A = W/ = W A = 
W B = 0. Assuming that the signal transi¬ 
tions at the primary input of simulation 
model A are not yet asserted, the value of 
K A is the minimum of W B ' and the W value 
(= °°) at the primary input of A. Thus, K A 
computes to 0. The value of K B is identical 
to W A and computes to 0. In Figure 13b, 
the signal transitions are asserted at the 
primary input of the simulation model A 
and are represented through two events — 
1,000T and Oi — of the event list of 
modelA and pseudocomponents A andA'. 
The event OJ. is at the head of the event 
queue and U A = 0. Since the U A value has 
changed from °° to 0, model A initiates 
pseudocomponents A andA'in Figure 13c. 
Pseudocomponents A and A' compute W A 
and W A , respectively. Because they differ 
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from their previous values, a chain reac¬ 
tion is initiated with the consequence that 
every W and W is updated, as shown in 
Figure 13c. When the executions of the 
components A and A' are complete, model 
A computes K A = minimum (“>,10) = 10, 
which exceeds the U A value of 0. Conse¬ 
quently, the event Ol of A is simulated. 

The model A executes the transition and 
generates a low-to-high transition at t = 5 
ns at its output. In Figure 13d, an event 5t 
of model B represents the output transition 
of A. Model B initiates pseudocomponents 
B and B'. Because neither W B nor W B ' 
changes, the executions of B and B' are 
immediately complete. Model B sends an 
acknowledgment to model A in Figure 13e. 
Then model A removes the already simu¬ 
lated event Ol from its event queue and 
updates U A . The new value of U A is 1,000, 
and model A again initiates pseudocompo¬ 
nents A and A'. The values of W A and W A 
are updated, but those of W B and W B remain 
unchanged. Model B computes K„ = mini¬ 
mum (W A ) =15, which is larger than the U B 
value of 5. As a result, the event 5t at B can 
be simulated. 

The execution of the transition by model 
B generates a high-to-low transition at t = 
10 ns at its output. This is represented as an 
event lOi at the input of A, as shown in 
Figure 13f. Model A initiates pseudocom¬ 
ponents A and A', which compute a new 
value for W A . All other W and W' values 
remain unchanged. Thus, the executions of 
A and A' are complete, and model A sends 
an acknowledgment to B. The incoming 
event 101 at the second input of A dis¬ 
places the event 1,000t at the head of the 
event queue and forces the new value of U A 
to be 10. Model B removes the already 
executed event 5? and sets U B = <*> in 
Figure 13g. It also initiates pseudocompo¬ 
nents B and B', with the result that none of 
the W or W’ values changes. In addition, 
model A computes K A = minimum (WV,°°) 
= 20, which exceeds the U A value of 10. 
As a result, the event 101 can be simu¬ 
lated. 

The simulation model A executes the 
transition but does not generate a new sig¬ 
nal value at its output. Consequently, model 
A removes the executed event 101 from its 
event list, updates U x , and then initiates 
pseudocomponents A and A'. The new 
value of U A is 1,000. The quantities W A and 
W A are computed to yield new values, and 
a chain reaction is initiated. The result is 
that W„ and W B values are also altered. 
Model A recomputes K A = minimum (°°, 
W B ) = 1,010, which exceeds the U A value 
of 1,000 with the consequence that the 


event 1,000? can be simulated. Although 
the entire design has stabilized and generated 
no new output values, the dataflow network 
computes updated values of W and W' that 
force the outstanding event — the external 
signal transition at t = 1,000 ns — to be 
simulated. 


Comparison with 
previous approaches 

In this section, we compare our algo¬ 
rithm with the two other principal algo¬ 
rithms proposed to avoid deadlocks. 3 ' 5 


transitions in T. 


' CZH 1 ' CZ 3 C3 CZ 3 

K U A ^B i i T U A 

-T>—HPlKi; 


K A ~m‘m(W B - 7)=min(0, ~)=0 

W.=o W g =0 


> n model 11,OOOt | 011 1 “I 11,000t| 0l| 1 ~| 




k a =o k b =o 

Wa —0 w g =o 


™ del S3 Ld . 11,OOOt[ol| 

U A Llo , , Ua Un 

K^minK 10)=10 > 0 

W‘ A = min(°°+5, ~+5, 0+5)=5(change) tV,=min(10+5, 0+5,)=5(change) 
W' B =min(5+5, ~+5)=10(change) W e = min(5+5, o=+5)=10(change) 

U A may be executed to produce a I to h transition at t = 5 at the output of A. 


[T555rRl fltl FwSfFH dll 

U A , U 8 U A U A 

;^ 1 >>-=!>>— 


tV' s =min(5+5, 5+5)=10(no change) W 0 =min(5+5,5+5)=10(no change) 


Figure 13. Snapshots of the simulation of the example design in Figure 12. 
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With the deadlock recovery algorithm, 5 
a simulation model does not propagate any 
output signal information to other models 
connected to its output port when its value 
as a consequence of execution remains 
unchanged. Therefore, other models whose 
execution depends on the output value of 


this model may not execute, and a dead¬ 
lock results. When such a deadlock occurs 
across the entire system, a distributed 
deadlock-detection mechanism detects the 
situation and a central entity synchronous¬ 
ly accesses the U and W values of every 
model, computes their minimum, and per¬ 



mits execution of all models up to the 
minimum value. 

In the Yaddes approach, the effect of 
any change in Wor W must ripple through 
the dataflow network as far as the effect 
can propagate. The crossbar switch implies 
transitive closure over all models in a 
feedback loop and guarantees that the U 
and W values of every simulation model 
that may possibly be affected by a change 
in the W or W value of a model will be 
updated. In addition, the minimum oper¬ 
ator used in the computation of every W, 
W, and K value ensures their correctness 
in the presence of multiple changes. The 
crossbar switch is equivalent to the tra¬ 
versal of all relevant loops in a design and 
computing the minimum over all relevant 
U and W values. 

The exception-mode algorithm 3 sends 
messages with incrementally increased 
time values, even when the logical values 
at the outputs are unchanged. Conse¬ 
quently, the simulation time up to which 
every model is simulated is advanced 
continuously. The mechanism is necessary 
because a model cannot view the global 
picture and see, for example, an unchanged 
external input signal. A consequent lim¬ 
itation is the potentially large number of 
messages in the system when the external 
input signal remains unchanged for long 
periods of time relative to the cumulative 
propagation delays of the models in the 
feedback loop. 

Yaddes, on the other hand, substitutes 
the global picture with the primed copy of 
the dataflow network. It permits optimistic 
jumps in the values of W\ assuming that 
future events will be unable to influence 
and modify them. Normally such optimism 
leads to inconsistency and error, but the 
crossbar switch and minimum operator 
ensure the correct advancement of the W 
value. 


Proof of correctness 

The proof of correctness of the Yaddes 
algorithm requires the correct execution 
of the simulation models, execution of 
events in the correct order, absence of 
deadlock, and the termination of simula¬ 
tion in finite time. The execution of a 
simulation model implies the execution 
of the model description, so the accuracy 
of the simulation model’s description also 
affects correctness. Complete details on 
the proof of correctness are presented 
elsewhere. 9 
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Figure 14. Yaddes performance measurements for a cross-coupled Nand latch (a, 
b). Performance measurements of the exception-mode algorithm for the same 
circuit (c). 


Implementation 

The implementation of the Yaddes algo¬ 
rithm is complex. Given any complex cir¬ 
cuit and a user-specified partition, the total 
number of processors required for simula¬ 
tion equals N+ 2, where N is the number of 
partitions. While the components of every 
partition execute on a processor, the algo¬ 
rithm models the primary inputs of the 
simulation circuit and the outputs of the 
dataflow network as entities P 0 and P u 
respectively, and executes them on unique 
processors. The entity P, signifies the 
rightmost boundary of the dataflow net¬ 
work and participates in the propagation of 
acknowledgments. If a circuit contains 
feedback loops, a preprocessor that gener¬ 
ates the dataflow network accepts the user- 
specified feedback arc set. 

Corresponding to every simulation cir¬ 
cuit component, the final implementation 
consists of three entities: a simulation model 
that represents the functionality of the 
component, and the primed and unprimed 
pseudocomponents. These are expressed 
through the C functions sim-component, 
ppc-component, and puc-component, re¬ 
spectively. Although they are concep¬ 
tually concurrent entities, in the current 
implementation they are executed round- 
robin on a processor. When a partition 
includes multiple models, we express an 
interconnection between two or more 
models on the same processor through a 
data structure. When the models are lo¬ 
cated on separate processors, an interpro¬ 
cessor protocol represents the connection. 

A significant part of the implementation 
consists of a kernel C description (approx¬ 


imately 2,500 lines) that executes on every 
processor except those that execute the 
entities P 0 and P,. Each processor accepts 
a unique input file that represents informa¬ 
tion on the models and pseudocomponents 
and their interconnection for the corre¬ 
sponding partition. The input files for the 
partitions are generated by a preprocessor 
that accepts a description of the circuit in 
the hardware-description language ESL 10 
and the user-specified partitions and feed¬ 
back arc set. 

During execution of the algorithm, the 
thread of control shifts from one entity to 
another. The algorithm first executes the 
simulation models — the sim-component 
functions — corresponding to the compo¬ 
nents that receive signal transitions from 
the external world at their primary input 
ports. A sim-component, in turn, initiates 
the executions of the puc-component and 
ppc-component functions, and suspends 
itself. When the executions of puc-compo¬ 
nent and ppc-component are complete, the 
sim-component is reactivated. The execu¬ 
tion of a puc-component (or ppc-compo¬ 
nent) is complete when either the W (or W') 
value at the output is unchanged or an 
acknowledgment is received, signifying 
that the change in the output W(or W') value 
has been propagated throughout the data¬ 
flow network. Additionally, the algorithm 
may initiate the puc-component and ppc- 
component functions for execution when 
they receive from the left a new W (or W) 
value at any of their input ports. Eventual¬ 
ly, the simulation process terminates when 
all events have been executed — that is, 
when the algorithm has used all externally 
supplied (usable) transitions at the primary 
input ports to generate output transitions. 


In principle, the Yaddes algorithm can 
be implemented on any generic parallel 
processor — Ncube, Armstrong, Sequent, 
BBN-Butterfly, or transputers. However, 
the loosely coupled parallel-processor ar¬ 
chitecture is the most realistic model of an 
actual complex asynchronous system such 
as a self-timed digital design, banking sys¬ 
tem, or packet network. Our principal aim 
in this article is to present the Yaddes 
algorithm as the first successful approach 
to asynchronous distributed discrete-event 
simulation of cyclic circuits on parallel 
processors. Compared with other ap¬ 
proaches, an asynchronous approach has 
the highest theoretical potential of using 
the most parallelism in a simulation. As 
with any asynchronous approach, the effi¬ 
ciency of Yaddes is realized for the simu¬ 
lation of systems whose models impose 
significant computational requirements and 
minimal need for data dependency or syn¬ 
chronization. Thus, Yaddes is not appro¬ 
priate for systems whose models require 
minimal computation and frequent syn¬ 
chronization. The pseudocomponents of 
the dataflow network that are synthesized 
in the Yaddes approach are purely mathe¬ 
matical entities which merely evaluate 
functions. The significant computational 
load is still confined to the simulation 
models. 

We implemented the Yaddes algorithm 
on the Armstrong 11 parallel-processor 
system at Brown University. Armstrong is 
a loosely coupled user-configurable paral¬ 
lel processor consisting of 100 processors. 
We reconfigured Armstrong as a six¬ 
dimensional hypercube. 

The principal purpose of our implemen¬ 
tation was to verify the correctness of the 
algorithm. In an experiment, we represent¬ 
ed and simulated a latch constructed from 
two cross-coupled Nand gates. We set the 
propagation delay for each gate at 500 ns, 
with the consequence that the cumulative 
propagation delay through the feedback 
loop was 1,000 ns. We chose the external 
transitions (termed input vectors in the 
digital design discipline) asserted at the 
primary inputs of the latch so the latch 
experienced both stability and oscillation. 
For the experiment, we varied the number 
of external transitions at both primary in¬ 
puts from 1,000 to 10,000 and measured 
the CPU time for each case. In addition, we 
selected three sets of average time periods 
for the external signals: 1,000,10,000, and 
100,000 ns. 
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The graphs in Figures 14a through 14c 
show the results. Figure 14a is a log-log 
graph where the y axis represents the CPU 
time in seconds and the x axis the number 
of external transitions asserted at the pri¬ 
mary input ports. The three overlapping 
graphs I, II, and III refer to the three sce¬ 
narios corresponding to the values 1, 10, 
and 100 of the ratio expressing the average 
time period of external transitions ( T) to the 
cumulative propagation delay around the 
loop (L,d t ). Figure 14b shows the same 
results as in Figure 14a, except that the x 
axis represents different values of the ratio 
TtLfle Figure 14c shows the results of 
simulation of the same circuit using the 
exception-mode algorithm, 3 also imple¬ 
mented on the Armstrong parallel-processor 
system. 

The graphs show that the performance 
of the Yaddes algorithm is independent of 
the ratio TI'L i d i and is consequently free 
from the limitations of the earlier algorithm. 3 
We plan to publish full details of perfor¬ 
mance issues for a number of complex 
sequential circuits simulated with Yaddes. 
These will show that Yaddes is a mathe¬ 
matically proved algorithm applicable to 
any complex sequential system. 


A synchronous distributed discrete- 
event simulation of cyclic circuits 
has the potential to address 
problems in digital hardware design, 
queuing networks, and banking transac¬ 
tions. Until now, no reported algorithm 
offered freedom from deadlock and ac¬ 
ceptable performance. The Yaddes algo¬ 
rithm, on the other hand, is mathematically 
correct and free from deadlock. 

The Yaddes approach opens the possi¬ 
bility of modeling as discrete-event sys¬ 
tems challenging problems from such dis¬ 
ciplines as banking, railway and mobile 
phone networks, sociological interactions, 
human decision-making processes, aircraft 
simulation, oceanics, and weather fore¬ 
casting. For example, we are studying the 
algorithm as a basis for distributed fault 
simulation using circuit partitioning, for 
distributed real-time banking systems, and 
for modeling large switching networks to 
investigate the role of overload conditions 
on network performance. ■ 
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ODM-Dialog 


An Experimental Speech-to-Speech 
Dialog Translation System 


Hiroaki Kitano, Carnegie Mellon University and NEC Corporation 


D eveloping a speech-to-speech 
translation system is an ultimate 
goal of natural language, speech 
recognition, and artificial intelligence re¬ 
search. This task requires recognition and 
understanding of speech in mixed-initia¬ 
tive dialogs and accurate translation and 
production of articulated audio output in 
real time (see Figure 1). 

Accomplishing this task will require the 
collective efforts of various researchers. 
The speech recognition module must ex¬ 
hibit highly accurate, real-time performance 
under speaker-independent, continuous- 
speech, large-vocabulary conditions. The 
machine translation module for parsing 
and generation must be capable of inter¬ 
preting the elliptical, ill-formed sentences 
that appear in real spoken dialog. In addi¬ 
tion, an interface between the parser and 
speech recognition module must pass nec¬ 
essary information to the parser and give 
appropriate feedback to the speech recog¬ 
nition module to improve recognition ac¬ 
curacy. 

No speech recognition module recog¬ 
nizes input speech with perfect accuracy; 
thus, it may provide a false word sequence 
as its first choice, but the correct word as its 
second- or third-best hypothesis. The pho¬ 
neme and word hypotheses it gives the 
parser consist of several competitive hy¬ 
potheses, each of which is assigned a prob¬ 
ability of correctness. Integrating speech 


This system — one 
of the first speech-to- 
speech translation 
systems, and the first 
to demonstrate 
simultaneous 
interpretation 
possibilities — has 
been implemented on 
several massively 
parallel machines. 


recognition and natural language process¬ 
ing improves recognition accuracy because 
it filters out false first choices and selects 
grammatically and semantically plausible 
second- or third-best hypotheses. To im¬ 
plement this mechanism, the parser needs 
to handle multiple hypotheses in parallel, 
not as single word sequences as in text- 
input machine translation systems. For a 


translation scheme, we assume use of in¬ 
terlingua — that is, a language-indepen¬ 
dent representation of sentence meaning 
— for efficient translation into multiple 
languages. A speech generation module 
must also generate appropriate spoken sen¬ 
tences with correct articulation control. 

In addition to these functional chal¬ 
lenges, real-time response is the major sys¬ 
tem requirement. Speech-to-speech dialog 
translation systems will be used for real¬ 
time transactions, which impose a more 
severe performance challenge than that for 
text-based machine translation systems. 
Furthermore, since a comprehensive sys¬ 
tem must handle two-way conversations, it 
should have bidirectional translation capa¬ 
bility. This should include the ability to 
understand interactions at the discourse 
knowledge level, predict next utterances, 
understand pronoun references, and pro¬ 
vide high-level constraints for generating 
contextually appropriate sentences in¬ 
volving various context-dependent phe¬ 
nomena. 

To attain these features, the overall pic¬ 
ture of the system should look like Figure 
2. The knowledge base in Figure 2 keeps 
track of discourse and world knowledge 
established during the conversation and is 
continuously updated during processing. 

Clearly, a speech-to-speech translation 
system is not just an assembly of existing 
speech recognition, machine translation. 
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and voice synthesis systems. Its develop¬ 
ment is a nontrivial task requiring new 
technologies. Completion is not in sight, 
but recent advances in related areas, espe¬ 
cially in speech recognition and natural 
language processing, have made it possi¬ 
ble to build prototypes. 

So far, three experimental systems have 
been developed: <t>DM-Dialog, an experi¬ 
mental system developed at Carnegie 
Mellon University’s Center for Machine 
Translation which this article describes; 
Speech Trans, another experimental system 
developed at the center, based on the pho¬ 
neme-based generalized LR parser 1 ; and SL- 
Trans, 2 a system developed by ATR Inter¬ 
preting Telephony Research Laboratories. 
These prototype systems are an important 
step toward a practical, full-scale system. 
Their development has helped define the 
nature of the problems we face and presented 
a new set of unanticipated problems. 


The ODM-Dialog 
project 


<bDM-Dialog is one of the first experi¬ 
mental speech-to-speech systems and is 
the first to demonstrate simultaneous inter¬ 
pretation possibilities. (The system’s name 
is a composite of the following: O is an 
abbreviation the center uses to indicate 
handling of speech input; DM means that 
the system, at least at its initial stage, is 
based on direct-memory-access parsing 
(DMAP) 3 ; Dialog indicates that the system 
translates two-way conversations.) The 
system accepts speaker-independent con¬ 
tinuous-speech inputs through custom 
speech recognition hardware, which pro¬ 
vides real-time output of phoneme se¬ 
quences, connected to the translation soft¬ 
ware system. Versions implemented on 
massively parallel computers have achieved 
translation within milliseconds. 

In addition to accomplishing spoken 
language translation in real time, the d>DM- 
Dialog project has two major research goals: 
establishing a model for simultaneous in¬ 
terpretation and a scheme for mixed-initia¬ 
tive dialog translation. 

To accomplish the first goal, ODM-Di¬ 
alog employs a radically new architecture. 
Parsing and generation processes are inte¬ 
grated and run concurrently using a hybrid 
parallel paradigm, which integrates a par¬ 
allel marker-passing scheme and a connec- 
tionist network. This approach attains an 
incremental production of sentences while 
parsing is in progress. 



Figure 1. Process flow of speech-to- 
speech translation. 


For the second goal, establishing a scheme 
for mixed-initiative dialog, we introduced 
a multiple-plan model with hierarchies for 
each participant. Traditional models use 
only a one-plan hierarchy. We also depart¬ 
ed from the traditional stack-based model. 4 
Our model uses a network to capture phe¬ 
nomena, such as misunderstandings and 
unexpected topic suspensions, observed in 
mixed-initiative dialogs. 

As a basic computational scheme, we 
employ a hybrid parallel model that com¬ 
bines parallel marker passing and a con- 
nectionist network. The marker-passing 
scheme is central to our model because it 


provides the symbolic processing that 
dominates natural language processing. 
Other marker-passing schemes 5 carry only 
bit vectors or activation source identifiers, 
but markers in our system carry such infor¬ 
mation as discourse entity, semantic and 
linguistic features, and a cost hypothesis. 
Five types of markers are passed around a 
memory network, which represents 
knowledge from the morphophonetic to 
the discourse level. Our marker-passing 
scheme also features a reliable, sophisti¬ 
cated control scheme for propagating 
markers. 

We are currently using the “conference 
registration” discourse domain based on an 
ATR Interpreting Telephony Laboratories 
corpus. In this highly interactive, mixed- 
initiative domain, the attendee asks ques¬ 
tions about conference registration and hotel 
reservations. The secretary not only an¬ 
swers these questions, but also asks his 
own questions. 

The major technical features of our sys¬ 
tem include (1) integration of speech and 
natural language processing, (2) almost 
concurrent parsing and generation, (3) dy¬ 
namic participation of discourse and world 
knowledge, (4) integration of case- and 
constraint-based processing, (5) a cost- 
based ambiguity resolution scheme, and 
(6) a massively parallel model. 

ODM-Dialog is implemented using CMU 
Common Lisp and runs on various work¬ 
stations. Connected hardware systems such 
as Matsushita Institute’s Japanese speech 
recognition hardware 6 and DEC Talk per¬ 
form speech input and voice synthesis. The 
memory network is written on the Frame 
Kit frame representation system developed 
at the center. We have also implemented a 
version of ODM-Dialog on a massively 
parallel associative memory machine IXM2 
from Electrotechnical Laboratory. 7 In ad¬ 
dition, a joint project between CMU and 
the University of Southern California has 
implemented a modified version of ODM- 
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Figure 2. Overall process flow of speech-to-speech dialog translation system. 
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Dialog, called DM-SNAP, on the Seman¬ 
tic Network Array Processor (SNAP) de¬ 
veloped at USC. 8 Also under way is an 
effort to implement our system on Think¬ 
ing Machine’s CM-2 connection machine. 

Model overview 

The model behind ODM-Dialog con¬ 
sists of a memory network for representing 
various knowledge levels and markers for 
inferencing. Markers in our model have 
rich informational content. Extended 
markers have a natural advantage over tra¬ 
ditional markers in capturing the parallel¬ 
ism inherent in natural language process¬ 
ing. The memory network provides easy, 
efficient access to contextual knowledge 
and enables highly interactive, dynamic 
participation at various knowledge levels. 

Memory network. The memory net¬ 
work incorporates all knowledge from 
morphophonetics to the plan hierarchies 
specific to each dialog participant, includ¬ 
ing both abstract and specific knowledge. 
Knowledge of specific cases is important 
because a considerable portion of human 
language comprehension and production 
is case based, that is, based on the memory 
of past experiences. 

Each node represents either a concept 
(concept class or CC node) or a sequence 
of concepts (concept sequence class or 
CSC node). CC nodes represent such 
knowledge as phonemes (for example, IkJ 
/a/), concepts (^Conference, *Event, 
*Mtrans-Action), and plans (*Declare- 
Want-Attend). CSC nodes represent se¬ 
quences of concepts and their relations for 
two dialog participants: for example, pho¬ 
neme sequences (/k a i g i/), concept se¬ 
quences (<*Conference *Goal-Role * At¬ 
tend *Want>), and plan sequences 
(<*Declare-Want-Attend *Listen-Instruc- 
tion>). 

In our model, concept sequences are the 
representations of an integrated syntax/ 
semantics level of knowledge. These se¬ 
quences can be used to represent abstract 
knowledge or specific cases. We assume 
the use of phrasal lexicons as generic pat¬ 
terns induced from a large sample of utter¬ 
ances and maps between specific surface 
representations and semantics. Also, syn¬ 
tactic knowledge at an abstract level can be 
represented. Currently, we use a Lexical 
Functional Grammar (LFG)-based frame¬ 
work for syntactic analysis. 

Each type of node creates instances dur¬ 
ing parsing, which are called concept in- 


(defLEX' (kaigi 
(Is-a (conference)) 

(language (japanese)) 

(surface (kaigi)) 

(gen-phon (ka i gi)) 

(sequence (k a i * i)))) 

(defLEX ’ (conference 
(is-a (conference)) 

(language (english)) 

(surface (conference)) 

(gen-phon (conference)) 
(sequence (K AA N F R AX N S)))) 


Figure 3. Lexical nodes for “kaigi” and 
“conference.” 


(<NP> <==> (<NP> <PostP>) 
(((xO head) == xl) 

((xO case) == (x2 case))) 


Figure 4. Grammar using a Lexical 
Functional Grammar-like notation. 


stances (CIs) and concept sequence in¬ 
stances (CSIs), respectively. CIs and CSIs 
correspond to discourse entities — mental 
objects referring to specific instances such 
as specific persons, events, or actions. Each 
node is connected through several types of 
links. A guided marker-passing scheme is 
employed for inference in the memory net¬ 
work. 

In our model, lexical items are repre¬ 
sented by CSC nodes applied to the lexical 
level, which we call lexical nodes. Each 
lexical node has knowledge of each 
word’s pronunciation in the form of a 
phoneme sequence. Figure 3 defines lexi¬ 
cal nodes for the Japanese word “kaigi” 
and the corresponding English word 
“conference.” “Kaigi” is a Japanese lexi¬ 
cal representation of a concept, “confer¬ 
ence.” Its surface representation for writ¬ 
ten text processing is “kaigi”; its symbol 
sequence for generation is “ka i gi”; and its 
recognition phoneme sequence is “k a i * i” 
(“*” represents a nasal phoneme). A lexi¬ 
cal node for the English word “confer¬ 
ence” has an expected phoneme sequence 


(K AA N FR AX N S) and other information 
similar to the Japanese lexical node. Each 
word has its own lexical node containing 
such information, and these definitions are 
compiled into the memory network. 

Grammar rules can be written using no¬ 
tations similar to Lexical-Functional 
Grammar (Figure 4) or semantic-oriented 
encoding (Figure 5). A semantic-oriented 
grammatical encoding method may be lin¬ 
guistically controversial (it provides less 
linguistic generalization than other for¬ 
malisms such as Lexical Functional Gram¬ 
mar or Head-Driven Phrase Structure 
Grammar). Nevertheless, its perplexity- 
reduction effects make it one of the best 
ways to write grammar for speech input 
parsing. Perplexity is a measure of the 
complexity of the task similar to an aver¬ 
age branching factor; a small perplexity 
measure means a task is rather simple. 
Generally, smaller perplexity improves the 
speech recognition module’s accuracy and 
response time. We extend the idea of se¬ 


mantic-oriented grammar to allow direct 
encoding of a surface string sequence into 
a specific case of utterances. Using specif¬ 
ic cases with stochastic measurement con¬ 
tributes significantly to perplexity reduc¬ 
tion, while strong constraints at the 
syntactic/semantic level can directly influ¬ 
ence the speech processing level. 

Markers. Markers are information-car¬ 
rying entities that pass through the memo¬ 
ry network to make inferences and pre¬ 
dictions. Our model uses five types of 
markers: 

• Activation markers (A-markers), which 
show node activation. 

• Prediction markers (P-markers), which 
are passed along the conceptual and 
phonemic sequences to make predic¬ 
tions about nodes to be activated next. 

• Contextual markers (C-markers), which 
are placed on nodes with contextual 
preferences. 

• Generation markers (G-markers), each 
of which contains a surface string and 


(<attend-action> <== (<attend> <event>) 

((xO = xl) 

((XO ACTION) = (xl root)) 
((xO OBJECT) = x2))) 


Figure 5. Grammar using semantic-oriented notation. 
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an instance representing the surface 

• Verbalization markers (V-markers), 
which anticipate and keep track of ver¬ 
balization of surface strings. 

A-markers carry information about a Cl 
node, probability/cost measures, linguistic 
and semantic features, and so forth. P- 
markers contain constraint equations, fea¬ 
ture structures, and a probability measure 
of the hypothesis. Figure 6 shows an exam¬ 
ple of information carried by an A-marker 
and a P-marker. 

G-markers are created at the lexical lev¬ 
el, and each contains a surface string, lin¬ 
guistic and semantic features, a cost mea¬ 
sure, and Cl nodes. G-markers are passed 
up through the memory network. At a certain 
point in processing, surface strings of G- 
markers are concatenated following the 
order of CSC nodes, and a final string of 
the utterance is created. During incremental 
sentence production, V-markers record the 
part of the sentence that i s already verbalized 
and anticipate the next possible verbaliza¬ 
tion string. 

The basic concept introduced in our 
model is probabilistic and structured paral¬ 
lel marker passing. Each marker carries a 
probability measure of the truth of its hy¬ 
pothesis. It also contains symbolic data 
such as linguistic features, pointers to dis¬ 
course entities, and constraints. This rich 
information dramatically increases the 
capability of the marker-passing scheme. 
The probability measure enables the sto¬ 
chastic analysis essential in processing 
speech inputs, and the linguistic features 
and discourse entities enable sound lin¬ 
guistic analysis. 

Parsing algorithm. ODM-Dialog fully 
employs a parallel marker-passing scheme 
for both parsing and generation. Because 
of the lexically guided, incremental gener¬ 
ation scheme, the algorithms for parsing 
and generation are very similar. 

A basic parsing algorithm can be divid¬ 
ed into several elemental operations: 

• Activate. A node is activated, and an 
A-marker is passed up through an Is-a link. 
Initial activation takes place at one or more 
CC nodes representing phonemes. 

• Shift. An A-marker hits an element in a 
CSC node that has a P-marker (A-P colli¬ 
sion), then the P-marker is moved to the 
next element of the CSC node (Figure 7a). 
In some cases, as seen in Figure 7b, a copy 
of the P-marker is made. The original P- 
marker moves to the next element, and the 


(A-MARKER0236 
(Probability: 0.14) 

(Cl Conference045) 

(Concept: Conference) 
(Feature: nil) 

(Type: Event) 

) 

(P-MARKER0196 
(Probability: 0.50) 
(Constraints: ((x0 = x2) 

((xOsubj) =x1)) 

(Feature: nil) 

> 


Figure 6. Example of an A-marker and 
a P-marker. 


copied P-marker skips the next element in 
the sequence. Such dual-prediction move¬ 
ments are used for phoneme-level process¬ 
ing. 

• Reduce. If an A-marker hits the last 
element of a CSC node and that element 
has a P-marker, the CSC node is reduced. A 
new A-marker, containing feature struc¬ 
tures established in the CSC node, will be 
passed up to higher CSC nodes. 

• Predict. When a shift places a P-mark- 
er on a new element of a CSC node, copies 
of the P-marker are passed down to nodes 
linked under the element. 

Figure 8 shows an example of how our 
algorithm parses an input with a simple 


p p 

PP P P 

<e 0 e 1 e 2 e 2 ... e> => <e 0 e l e 2 e } ... e> 

<e g e { e 2 e 2 ... e> => <e 0 e, e 2 e 3 ... e> 

t 

T 

A 

A 

(a) 

(b) 


Figure 7. Movement of P-marker: (a) simple prediction; (b) dual prediction. 



Figure 8. Parsing with a small grammar: (a) initial prediction; (b) input a causes 
A-P collision; (c) shift and predict; (d) input b; (e) shift and predict; and (f) in¬ 
put c causes reduction in <*D *E> and <*A *B>. 
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grammar (the actual memory network is 
highly layered and indexed). Phrase struc¬ 
ture rules are mapped onto CSCs, and each 
preterminal and terminal symbol is mapped 
onto CCs and lexical nodes, respectively. 

At Figure 8a, P-markers are initialized 
and passed down to predict starting sym¬ 
bols. At Figure 8b, activation of node a 
triggers propagation of an A-marker from 
node a to node C, to node A, and to node 
*A. A-marker propagation to element *A 
of CSC <* A *B> causes an A-P collision at 
* A. In Figure 8c, the P-marker is shifted to 
the next element of the CSC (element *B). 
Then, a P-marker is passed down to predict 
the next possible inputs, from element *B 
to element *D, and to node b. Also, a P- 
marker is passed down from element *B to 
node F, and to node d. In Figure 8d, the 
activation of node b triggers an A-marker 
propagation from node b to node D, result¬ 
ing in an A-P collision at <*D *E>. Figure 
8e shows a shift of a P-marker and top 
down prediction with a P-marker to node c. 
At Figure 8f, activation of node c triggers 
the reduce operation, first, at <*D *E> and 
then at <*A *B>. Finally, an A-marker 
activates S, and the input sentence is ac¬ 
cepted. 

Integrating speech and 
natural language 
processing 

A speech-based natural language sys¬ 
tem requires integration of speech recog¬ 
nition and natural language processing to 
improve the recognition rate of the speech 
inputs. This integration permits a more 
appropriate assignment of an a priori prob¬ 
ability to each hypothesis and imposes more 
constraints to reduce search space than 
simple stochastic language models. Thus, 
the quality of the language model is an 
important factor, and a sophisticated pars¬ 
ing and discourse understanding scheme is 


necessary for accurate translation from 
speech input. Our system employs an ar¬ 
chitecture for parsing speech inputs that 
integrates speech (phonological-level 
processing) and natural language processing 
with full syntactic/semantic analysis and 
discourse understanding. 

For the current implementation, we use 
Matsushita Institute’s Japanese speech 
recognition system 6 to provide a phoneme- 
level sequence. (We’re investigating di¬ 
rect interface with high-performance- 
speech recognition modules based on the 
Hidden Markov Model and Time Delay 
Neural Network. See Waibel and Lee 9 for 
details of current speech recognition re¬ 
search). Because of recognition errors, the 
device gives a phoneme sequence that 
contains substitutions, insertions, and de¬ 
letions — that is, a noisy phoneme se¬ 
quence. 

The task of phonological-level process¬ 
ing is to hypothesize the correct sequence 
from this noisy sequence. Inevitably, 
multiple hypotheses can be generated due 
to the stochastic nature of phoneme rec¬ 
ognition errors. Thus, we want a measure 
of correctness assigned to each hypothesis. 
In the stochastic speech-recognition mod¬ 
els, a probability of each hypothesis is 
determined by P(y\h) x P(h). P(y\h) is the 
probability of an input sequence being ob¬ 
served when a hypothesis h is articulated. 
P(h) is an a priori probability of the hy¬ 
pothesis derived from the language model. 
An a priori probability is a probability that 
certain hypotheses could be correct. For 
example, suppose that a word wl is always 
followed by a word w2, and the recognition 
system determined that the word just spo¬ 
ken is wl. In this case, the a priori proba¬ 
bility of w2 being the next word is 100 
percent. 

When phonological-level processing is 
the same, the system with a more sophisti¬ 
cated language model attains a higher rec¬ 
ognition rate because the a priori probabil¬ 
ity differentiates between hypotheses of 


high acoustic similarity that would other¬ 
wise lead to confusion. At the same time, 
we want to eliminate less-plausible hy¬ 
potheses as early as possible to keep the 
search space within a certain, workable 
size. We use syntactic/semantic and dis¬ 
course knowledge to impose constraints 
that reduce search space, in addition to the 
probability-based pruning within the pho¬ 
nological level. 

We assume a noisy phoneme sequence 
(Figure 9) as the phonological-level pro¬ 
cessing input. To capture the stochastic 
nature of speech inputs, we adopt a proba¬ 
bilistic model similar to that used in other 
speech recognition research. First, we de¬ 
scribe a simple model using a static prob¬ 
ability matrix; in this model, probability is 
context independent. Then, we extend the 
model to capture context-dependent prob¬ 
ability. 

Speech processing. The system’s pho¬ 
neme-level activities begin with noisy 
phoneme sequences that contain phoneme 
insertions, deletions, and substitutions. For 
example, /t a i * i/ or /k a i i/ are noisy 
phoneme sequences for “kaigi,” which 
should be recognized as /k a i * i/. (Each 
character represents a separate phoneme.) 
The probability measures involved in pro¬ 
cessing are an a priori probability given by 
the language model, a confusion probabil¬ 
ity given by a confusion matrix, and a 
transition probability given by a transition 
matrix. 

• A priori probability. This probability 
is derived from the language model and is 
a measure of which phoneme sequence is 
likely to be recognized. 

• Confusion matrix. This matrix defines 
the output probability of a phoneme when 
an input symbol is given. The output prob¬ 
ability is a probability measure that the 
input sign will be recognized as a pho¬ 
neme pj. The confusion matrix c tJ defines 
the output probability distribution between 


kaigi ni sanka shitai nodesu 


DAI*I*IPAUTAQPAINO*EKU 
BAII*IPAA=KAS@PAINODUSU 
BAII*I*IPAU=KAIQPAI*0*ESU 
KAIIMIP A A=KAS @ PEEPODESU 
KAI*I*IPAA=ZAS @ PAIWO*USJU 


youshi ha arimasuka 


BJOHIRAARI*ATAWA 

JOSJUWAARINAOQZAA 

IOUSIWAARIMAUQKA 

JOOSIHAKARI*AUQKA 

IOOSJUWAWARI*AACA 


onamae wo onegai shimasu 


0*A*AEJOORE*EISI*AS @ 

WO*A*AEJOORE*EEHJANA 

WONA*AEJOBO*E*EIHJAH@ 

0*A*AEJ0*0*E*EEISINAKU 

0*A*AEJOO*E*EEIHJAZU 


Figure 9. Examples of noisy phoneme sequences. 
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all pairs of input signs and phonemes. It is 
a measure of the distance between symbols 
and phonemes, as well as a measure of the 
cost of hypotheses that interpret the sym¬ 
bol s, as the phoneme p r In the context- 
dependent model, the confusion matrix will 
be defined as c tjk , which gives a probability 
that symbol s, will be interpreted as pho¬ 
neme pj at a transition tr k from s,_i to s t . We 
call this matrix adynamic confusion matrix. 

• Transition matrix. This matrix defines 
the probability that symbol s M will follow 
symbol s f . For an input sequence .v 0 , j„ ..., 
s„, the a priori probability of transition 
between j 0 and s, is given by t So Sl . Since we 
have a finite set of input symbols, each 
transition can be indexed as tr k . The tran¬ 
sition probability and the confusion prob¬ 
ability are intended to capture the context 
dependency of phoneme substitutions — a 
phenomenon whereby a phoneme can be 
articulated as other phonemes in certain 
environments. 

Initially, P-markers contain an a priori 
probability (n,) given by the language 
model. The P-markers are placed on each 
first and second element of conceptual se¬ 
quence class nodes that represent expected 
phoneme sequences. For an input symbol 
s,, A-markers are passed up to all phoneme 
nodes that have a probability (c :j ) greater 
than the threshold (th). When a P-marker, 
which is at ith element, and an A-marker 
collide, the P-marker is moved to the i'+lth 
and i+2th elements of the sequence (this is 
a dual prediction). When the next input 
symbol j 1+1 generates an A-marker that hits 
the P-marker on the i +1 th or i+2th element, 
the P-marker is moved using the dual pre¬ 
diction method. The probability density 
measure computed on the P-marker is 

ppm(i) =ppm(i-l) x 

ppm{ 1) = ppm(O) x f onset io 

ppm(0) = Jt, 

Here, ppm(i) is a probability measure of 
a P-marker at the ith element of the CSC 
node, which is a probability of the input 
sequence being recognized as a phoneme 
sequence traced by the P-marker. And 
lonsn. is a transition probability from the 
onset to the first phoneme, that is, the 
probability of the phoneme to be given as 
a first phoneme of inputs. The context- 
dependent model is 

ppm(i) =ppm(i-\) x X c PtiJilk 


where k denotes a transition from s t _ 2 to 

Figure 10 shows a simplified view of 
this process. We suppose an input pho¬ 
neme sequence to be “DAI*I...”. Each in¬ 
put phoneme activates phoneme hypothe¬ 
ses based on a confusion matrix. For 
example, an input phoneme “D” activates 
phoneme hypotheses “t”, “k”, “d”, “g”, 
and with corresponding probability 
measures. For the sake of simplicity, the 
transition probability is not drawn in this 
figure. A path shown by a thick solid line 
shows a lexical hypothesis for KAIGI 
(conference), a thick dashed line shows 
GOMI (garbage), and a thin dashed line 
shows GOEI NE... (guard and part of a 
following word). In activating lexical hy¬ 
pothesis GOMI, the third input phoneme 
“I” is considered noise; thus, the path ignores 
either “i” or “e” activated by “I.” On the 
other hand, a path for GOEI has a transition 
that adds a phoneme not appearing in the 
input phoneme sequence; a phoneme “o” is 
inserted while transiting from “g” to “e.” 

Our context-dependent model is quite 
similar to the Hidden Markov Model when 
the transitions of the state of P-markers are 
synchronously determined by, for exam¬ 
ple, certain time intervals. This implies 
that we could employ the Hidden Markov 
Model as our speech recognition model 
within the current framework. Also, inte¬ 
gration with neural network-based speech 
recognition is straightforward. 

Language model. The language model 
analyzes the meaning of utterances in the 
context of a discourse and provides top- 
down predictions regarding the next possi¬ 
ble words in the form of an a priori proba¬ 
bility. Simply connecting a conventional 


parser on top of a speech recognition mod¬ 
ule does not suffice for the second task, 
because preterminal symbols (noun, verb, 
preposition, adjective) are, in most cases, 
too abstract to limit the next possible words. 
However, a more statistical approach, such 
as word-pair grammar, N-gram, or a sto¬ 
chastic finite-state network, does not reflect 
linguistic constraints or analyze the meaning 
of utterances. It provides a set of possible 
words at each analysis point but does not 
interpret sentences. Thus, this approach 
makes it difficult to reflect linguistic con¬ 
straints, since appropriate constraints can 
be imposed only by analyzing sentence 
semantics. (See Waibel and Lee 9 for a good 
collection of papers on various language 
models.) Our approach is to integrate uni¬ 
fication- and case-based parsing and to 
employ stochastic marker passing in which 
markers carry a probabilistic measure. 

Syntactic/semantic analysis. Utterances 
are interpreted in three levels of abstrac¬ 
tion: specific cases, generalized cases, and 
unification grammar. Specific cases are 
utterances stored by word sequence and 
meaning. This knowledge is indexed in the 
memory network and reactivated when 
similar utterances occur. Generalized cas¬ 
es involve similar utterances, which are 
indexed to more abstract nodes and pro¬ 
cessed with some feature and constraint 
checks. They are similar to semantic- 
oriented grammar. 

Unification grammar is a set of rules that 
reflect syntactic knowledge. As the most 
abstract level of knowledge in a syntactic 
processing layer, it involves more features 
to constrain the syntactic structure of the 
parse. Given a certain threshold in an a 
priori probability, perplexity can be effec- 
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((ACTION WANT004) 

(ACTOR (Cl: 1023)) 

(CIRCUMSTANCE ((ACTION ATTEND 109) 

(ACTOR (Cl: 1023)) 

(OBJECT (Cl: CONFERENCE002))))) 


Figure 11. Meaning representation. 


tively reduced with layered levels of pro¬ 
cessing (described later). Sentence mean¬ 
ings are already associated for specific 
cases, while the more abstract generalized 
cases and unification-based processing build 
up meaning representation. Features are 
aggregated when A-markers are passed up, 
so minimal features are involved in the 
expensive unification operation. Feature 
aggregation is necessary so that more fea¬ 
tures can be carried in parsing with more 
abstract knowledge. Because of preindex¬ 
ing, processing with specific cases does 
not require feature unification. Each CSC 
node representing abstract knowledge has 
constraint equations (except for nodes 
representing specific cases, which are al¬ 
ready instantiated and indexed in the 
memory network). These equations define 
the constraints imposed for that CSC node 
and level of abstraction. 

Feature structures and constraint equa¬ 
tions interact at two stages. At the predic¬ 
tion stage, if a P-marker placed on the first 
element of the CSC node already contains 
a feature structure that is non-nil, the fea¬ 
ture structure determines (according to the 
constraint equations) the possible feature 
structures that subsequent elements can 
receive for that interpretation to be accept¬ 
able. At an A-P collision stage, the A- 
marker’s feature structure is tested for 
agreement with the anticipated structure. 
If the feature structure passes this test, 
information in the A-marker and the P- 
marker are combined, and more precise 
predictions are made about what will be 
acceptable in subsequent elements. 

An example of feature structure build¬ 
ing as a result of parsing is shown in Figure 
11. The feature structure represents a 
meaning of the sentence parsed and con¬ 
tained in an A-marker, which further 
propagates up into the discourse-level 
memory network. 

Plan-based discourse recognition. We 
use hierarchical domain plan sequences, 
represented by CSC nodes, to recognize 
and predict the next possible utterances. 
Plan hierarchies organized for each partic¬ 


ipant capture the complexities that often 
take place in a mixed-initiative dialog. This 
is a maj or difference between our discourse 
model and others, such as Litman and 
Allen’s. 4 

Each element of the plan sequence rep¬ 
resents a domain-specific instance of a 
plan dynamically derived from abstract 
dialog knowledge and domain knowledge. 
Interactions are represented as a transition 
between CC nodes that represent a specific 
domain plan. Thus, the context of the cur¬ 
rent discourse is captured as an incremen¬ 
tally built network state, in contrast to the 
shared-stack state of Litman and Allen’s 
model. Using a network that links each 
speaker’s domain plan overcomes the 
problem of discourse context in the shared 
stack, where both speakers must agree on 
intent to obtain a correct representation — 
an assumption that is too strict for model¬ 
ing mixed-initiative dialog, since two 
speakers may not share domain plans and 
goals. Such misunderstandings cannot be 
modeled in the shared-stack model; how¬ 
ever, in a network representation, utterances 
subject to different interpretations can be 
linked to the different domain plans in each 
speaker’s plan hierarchy. Our model also 
differs from the scripts or memory orga¬ 
nization packets (MOPs) used in case-based 
models, 3 which are simple sequential 
memory structures with no internal struc- 

Our abstract plan sequences are similar 
to Litman and Allen’s 4 plan schemata in 
that they represent generic constraints and 
relationships between an utterance and a 
domain plan. They consist of parameter¬ 
ized knowledge and domain-independent 
knowledge of discourse plans. In contrast, 
specific plan sequences are domain-spe¬ 
cific. They are regarded as records of past 
cases already indexed in memory. Thus, 
most constraints are already imposed, and 
the sequence is indexed according to the 
specific constraints. Our CSC nodes, also 
similar to Litman and Allen’s, represent 
domain plans consisting of (1) header, (2) 
Is-a, (3) constraints, (4) decomposition, 
and (5) effect. We added an Is-a link be¬ 


cause we use a hierarchical network 
model. 

Discourse entities and their relations. 
Discourse entities and their relations are 
established as a result of understanding the 
utterances in the dialog. Understanding in 
d>DM-Dialog is regarded as the activity of 
dynamically modifying the memory net¬ 
work as a result of parsing. The memory 
network is modified in two ways: (1) by 
creating a new instance, representing dis¬ 
course entity, in the network and (2) by 
creating and deleting links between nodes. 
As each utterance is processed, Cl nodes 
are created under CC nodes representing 
discourse entities. Concept instance nodes 
are created when new discourse entities are 
introduced and utterances are processed, 
and they are referred to later. Another type 
of Cl node represents the meaning of the 
specific utterance. Such nodes are record¬ 
ed in the memory network as utterance 
cases in the specific discourse context. 
This type of Cl node has links such as (1) 
an abstraction link to a CC node, (2) links 
to each speaker’s plan hierarchy, (3) a 
speaker link that shows the speaker of the 
utterance, (4) a hearer link that shows the 
hearer of the utterance, and (5) links that 
establish propositional content. In addi¬ 
tion, each CSC node has world knowledge 
that triggers modification of the memory 
network to reflect what was told to the 
system. This knowledge is particularly 
important in resolving ambiguities and 
identifying anaphoric references. 

Prediction. Predictions are provided in a 
top-down manner. When A-markers are 
passed up, a probability measure for each 
hypothesis is carried up. At each shift ac¬ 
tion, a prediction is associated, and P- 
markers are passed down. During this pro¬ 
cess, a probability measure should be 
preserved in branching and merging — the 
sum of probabilities of incoming markers 
and outgoing markers should be equal 
(Figure 12). Case-based parsing provides 
the most specific prediction and gives a 
high a priori probability. More abstract 
knowledge provides less specific predic¬ 
tions and a weaker a priori probability. To 
handle totally unexpected utterances, some 
probabilities are assigned for words pre¬ 
dicted from a unification-based process 
instead of a case-based process. 

Figure 13 shows propagation of proba¬ 
bility measures in a simple network. Each 
word is activated with a probability mea¬ 
sure given by the speech recognition unit, 
and A-markers propagate upward through 
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Figure 12. Branching (a and b) and merging (c and d) of markers. 



the memory network. Branching and 
merging and syntactic and semantic anal¬ 
yses take place during this process. Proba¬ 
bility measures are summed or divided at 
the “predict” stage as the P-markers come 
down the network. When a P-marker reaches 
the word level, each word is assigned an a 
priori probability. 

With a certain threshold value, we ob¬ 
tained an experimental result that shows 
the scheme’s effectiveness in relatively 
small tasks. Our preliminary results are 
consistent with a report by Young’s group, 10 
which demonstrate the usefulness of dis¬ 
course-level prediction in improving speech 
recognition accuracy. On a small, uncon¬ 
strained test set with a 247.0 word-choice 
perplexity, syntactic and semantic con¬ 
straints reduced perplexity to 19.7. Adding 
discourse-level constraints reduced it to 
2.4, but, again, this is not necessarily the 
case in wider domains. Further, by intro¬ 
ducing threshold relaxation search, the 
search space can be effectively narrowed, 
initially with a high threshold, and then 
expanded (by decreasing the threshold) 
until a reasonable solution is found. 

Cost-based ambiguity 
resolution 

We used a cost-based scheme of ambi¬ 
guity resolution in ODM-Dialog. In the cost- 
based theory, the hypothesis with the least 
cost will be selected. This principle applies 
to both the parsing and generation process¬ 
es. In the speech-input natural-language 
system, ambiguity caused by noisy speech 
inputs is added along with lexical and 
structural ambiguities. The cost-based ap¬ 
proach enables us to handle these different 
levels of ambiguity in a uniform manner. 
In the parsing process, costs are added 
when (1) new Cl nodes are created, (2) CC 
nodes without contextual priming are used 
for further processing, and (3) the memory 
network is modified to satisfy constraints. 
Costs are subtracted when (1) a prediction 
has been made from discourse knowledge 
and (2) CC nodes with contextual priming 
have been used. In the cost-based disam¬ 
biguation scheme, we choose the least costly 
hypothesis. More detailed explanations of 
each process affecting cost are given be¬ 
low. 

Initial conditions. Because our model 
parses utterances under a given context, 
the cost assigned to a hypothesis is not 
always the same. The cost depends on the 


context and the initial conditions an utter¬ 
ance gives the system. The system’s initial 
condition is based on previous discourse. 
Major factors are the memory network’s 
state, contextual priming, and predictions 
from discourse plans. The memory net¬ 
work is modified as a result of processing 
previous utterances. Contextual priming 
(node preactivation as a result of context 
inferencing) is imposed by C-marker 
passing or by a connectionist network. The 
mechanism of assigning the preference is 
based on the top-down prediction using 
discourse knowledge. 

Phonological processing. The proba¬ 
bility measure at the phoneme processing 
level is converted to a cost measure. For 
each hypothesis, a corresponding lexical 
entry is activated. 

Reference to the discourse entity. When 
a lexical node activates any CC node, a Cl 
node under the CC node is searched for. 
This activity models reference to an al¬ 
ready established discourse entity in the 
hearer’s mind. If such a Cl node exists, the 
reference succeeds, and this parse will be 


attached with no cost. However, if no such 
instance is found, reference failure results. 
If this happens, an instantiation activity 
creates a new instance with certain costs. 
As a result, a parse using a newly created 
instance node will be attached with some 


Contextual priming. In our system, some 
CC nodes designated as contextual root 
nodes have a list of thematically relevant 
nodes. C-markers are sent to these nodes as 
soon as a contextual root node is activated. 
Thus, each sentence and/or each word might 
influence the interpretation of following 
sentences or words. When a node with a C- 
marker is activated by receiving an A- 
marker, the activation will be propagated 
with no cost. Thus, a parse using such 
nodes would have no cost. However, when 
a node without a C-marker is activated, a 
small cost is attached to the interpretation 
using that node. 

Constraints. Constraints are attached to 
each CSC node. These constraints play 
important roles during disambiguation. 
Constraints define relations between in- 
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Figure 14. Movement of V-marker in the concept sequence class nodes. 


stances when sentences or sentence frag¬ 
ments are accepted. When a constraint is 
satisfied, the parse is regarded as plausible. 
On the other hand, the parse is less plausi¬ 
ble when the constraint is unsatisfied. Tra¬ 
ditional parsers simply reject parses that 
do not satisfy a given constraint, but ours 
builds or removes links between nodes, 
forcing them to satisfy constraints. A parse 
with forced constraints will record an in¬ 
creased cost and will be less preferred than 
parses without attached costs. 

Parallel incremental 
generation 

One unique feature of <5DM-Dialog is its 
simultaneous interpretation capability, 
which is made possible by an incremental 
parsing and generation algorithm. Deter¬ 
mining the meaning of part of an input 
utterance triggers verbalization in the gen¬ 
eration process; thus, part of an input sen¬ 
tence can be translated in the target language 
before the parser receives an entire sentence. 

Baseline generation algorithm. Natu¬ 
ral language generation usually involves 
several stages: content delineation, text 
structuring, lexical selection, syntactic se¬ 
lection, coreference treatment, constituent 
ordering, and realization. In our model, the 
content is determined at the parsing stage. 
Most of the other processes are unified in 
one stage; that is, the lexical item, phrase, 
and sentence are treated in the same mech¬ 
anism. The common thrust in our model is 
the hypothesis-activation-selection cycle, 
in which multiple hypotheses are activated 
and one is finally selected. Thus, the 
translation process consists of the follow¬ 
ing steps. 

(1) Concept activation. This is a part of 
the parsing process as well as an initial 
generation process. Individual concepts 
represented by CC nodes are activated as a 


result of parsing speech inputs. A-markers 
are created and passed up by activating the 
concept. 

(2) Lexical and phrasal hypotheses ac¬ 
tivation. Hypotheses for lexicons and 
phrases that represent the activated con¬ 
cept are searched for, and G-markers are 
created and passed up as a result of this 
process. This process is triggered by acti¬ 
vation of certain CC nodes by A-markers 
in the parsing stage. Usually, multiple can¬ 
didates are activated at one time. 

(3) Propositional content activation. 
This part of the parsing process determines 
the utterance’s propositional content. 

(4) Syntactic and lexical selection. This 
stage selects one hypothesis from multiple 
candidates of lexical entries or phrases. 
The selection is invoked when certain 
propositional content is determined in the 
parsing stage. First, the syntactic and se¬ 
mantic constraints are checked to ensure 
hypothesis correctness. The final selection 
is cost/activation based. 

(5) Realization. The surface string 
(which can be either a sequence of words 
or a sequence of phonological signs) is 
formed from the selected hypothesis and 
sent to the speech synthesis device. 

The system uses verbalization markers 
(V-markers) and generation markers (G- 
markers) for the generation process. First, 
a V-marker is located on the first element 
of the CSC node. When a G-marker hits the 
element with the V-marker, the V-marker 
is moved to the next element of the CSC 
node (Figure 14a), and unification is per¬ 
formed to ensure syntactic soundness of 
the sentence. In Figure 14b, a, is a closed- 
class lexical item. (Closed-class lexical 
items refer to function words such as “it,” 
“in,” “of,” and “at” in English and “it,” 
“wo,” “ga,” and “ni” in Japanese. These 
words are nonreferential, and their number 
does not grow. Open-class lexical items 
are mostly referential, and their number 
grows as vocabulary expands.) 

When a G-marker hits the first element, 


a V-marker (on the first element) is moved 
to the third element by passing through the 
second element, which is a closed-class 
item. In this case, the element for the closed- 
class item need not have a G-marker. The 
lexical realization for the element is re¬ 
trieved when the V-marker passes through 
the element. If G-marker hits an element 
without a V-marker, the G-marker is stored 
in the element. When another G-marker 
hits the element with a V-marker, the V- 
marker is moved to the next element. Since 
the next element already has a G-marker, 
the V-marker is further moved to the sub¬ 
sequent element of the CSC node (Figure 
14c). 

Although, in most cases, a bottom-up 
process by G-markers handles generation 
process, there are cases where a bottom-up 
process alone cannot identify syntactic 
structure and lexical items to express a 
given meaning. Such cases invoke a top- 
down process that identifies the best syn¬ 
tactic structure and lexical items by 
searching downward from each element of 
the activated CSC node. Each retrieval 
procedure is similar to the search of a 
closed-class lexical item. 

In some cases, an element of the CSC 
node is linked to other CSC nodes to form 
hierarchies. Suppose each CSC node rep¬ 
resents a phrase structure rule, then the 
dynamically organized CSC node hierar¬ 
chy provides productive power so that 
various types of structures in complex 
sentences can be generated. In the hierar¬ 
chy of CSC nodes, G-markers are passed 
up when a CSC node is accepted. They 
carry feature structures that represent 
meaning fragments expressed by the CSC 
node. V-markers are passed down to lower 
CSC nodes when an element is predicted. 
They impose constraints on each element 
of the lower CSC nodes. The hierarchical 
organization of CSC nodes allows all types 
of tree expansion: upward, downward, and 
insertion. 

Figure 15 shows the construction of an 
analysis tree in our model. In this example, 
we assume Lexical Functional Grammar 
as a grammar formalism, and the order in 
which conceptual fragments are given is 
based on the order in which they can be 
identified in incremental parsing of a cor¬ 
responding Japanese sentence. Note that 
our model does not necessarily assume a 
special grammar, as is the case in other 
incremental generation models such as 
Kempen and Hoenkamp’s." 

Figure 16 shows variations in generated 
sentences due to the differences in the 
order of input concept fragments. In Figure 
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16a, concept fragments are given in the 
order of (OBJECT JOHN), (ACTION 
SURPRISE), and (ACTOR MARY). This 
order generates a passive-voice sentence. 
However, in Figure 16b, conceptual frag¬ 
ments are given in the order of (ACTOR 
MARY), (ACTION SURPRISE), and 
(OBJECT JOHN), which creates an active- 
voice sentence. This flexibility of sentence 
structure, which depends on the order and 
timing of an input concept fragment, is an 
essential feature for an incremental sen¬ 
tence-production scheme. 

Activating lexical and phrasal hy¬ 
potheses and propositional contents. 

When the parsing process recognizes a 
concept, it activates a translation hypothe¬ 
sis. The concept can be an individual con¬ 
cept, a phrase, or a sentence. In our model, 
they are all represented as CC nodes, and 
each instance of the concept is represented 
as a Cl node. The basic process is for each 
of the activated CC nodes, LEX nodes 
(which represent a lexical entry and a 
phonological realization of the word), in 
the target language to be activated. There 
are four possible mappings between source 
language nodes and target language nodes 
which are activated; word-to-word, phrase- 
to-word, word-to-phrase, and phrase-to- 
phrase. In our model, hypotheses for sen¬ 
tences and phrases are represented as CSC 
nodes. From the viewpoint of generation, 
either LEX nodes representing words or 
CSC nodes representing phrases, or entire 
sentences, are activated. 

LEX node activation. There are cases 
when a word or a phrase can be translated 
into a word in the target language. In Fig¬ 
ure 17a and 17c, the word LEX sl or the 
phrase CSC SL activates CC,. (Subscripts SL 
and TL denote a source language and a 
target language.) LEXl^ is activated as a 
hypothesis of translation for LEX sl or CSC SL 
interpreted as CC,. A G-marker created at 
LEX Ijl contains a surface realization, cost, 
features, and an instance that the LEX1 tl 
represents (Cl). The G-marker is passed up 
through an Is-a link. When a CC1 does not 
have LEXI-tl, a CC 2 is activated and a 
LEX2-TL will be activated. Thus, the most 
specific word in the target language will be 
activated as a hypothesis. 

CSC node activation. When a CC can be 
represented by a phrase or sentence, a CSC 
node is activated and a G-marker contain¬ 
ing that phrase or sentence will be created. 
In Figure 17b and 17d, LEX sl and CSC SL 
activate CC„ which has CSC 1^. In this case. 



Figure 15. An incremental tree construction. (S, sentence; NP, noun phrase; VP, 
verb phrase; PP, prepositional phrase; N, noun; V, verb; and P, preposition.) 



Figure 16. Change of produced sentence due to different semantic inputs. 
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Figure 17. Lexical, phrasal hypotheses activation. 
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Figure 18. Transaction with (a) conventional sequential and (b) simultaneous in¬ 
terpretation architectures. 


CSC 1 TL will be activated as a hypothesis to 
translate LEX sl or CSC SL interpreted as CC,. 
Activation of CSC1 TL by CSC SL is partic¬ 
ularly interesting because it covers cases 
where two expressions can be translated 
only at phrasal or sentential correspon¬ 
dence, not at the lexical level. Such cases 
are often found in greetings or canned 
phrases. 

Syntactic and lexical selections. Syn¬ 
tactic and lexical selections involve three 
processes: feature aggregation, constraint 
satisfaction, and competitive activation. 

Feature aggregation and constraint sat¬ 
isfaction correspond to a symbolic approach 
to syntactic and lexical selection, which 
guarantees the grammaticality and local 
semantic accuracy of the generated sen¬ 
tences; the competitive activation process 
is added to select the best of multiple can¬ 
didates. Like the parsing stage, generation 
uses specific cases, generalized cases, and 
syntactic knowledge. Features are carried 
up by G-markers and grammaticality is 
checked when a G-marker collides with a 
V-marker. In this process, only syntacti¬ 
cally and semantically sound hypotheses 
can survive. 

Competitive activation, introduced by 
either a C-marker passing scheme or the 


connectionist network, determines the fi¬ 
nal syntactic and lexical realization of the 
sentence. Here, we have adopted a cost- 
based scheme, like the one used in parsing, 
that selects the hypothesis with the least 
cost. This idea reflects our view that pars¬ 
ing and generation are dynamic processes 
in which the state of the system tends to a 
global minimum, and that a cost represents 
dispersion of energy so that higher cost 
hypotheses are less likely to be taken as the 
state of the system. In the actual implemen¬ 
tation, we compute the cost of each hy¬ 
pothesis, which is determined by a C-marker 
passing scheme or a connectionist network. 

C-marker passing scheme. This scheme 
puts C-markers at contextually relevant 
nodes when a conceptual root node is acti¬ 
vated. A G-marker that goes through a 
node without a C-marker will be added 
with larger cost than others. When there 
are multiple hypotheses for the specific CC 
node — that is, when multiple CSC nodes 
are linked with the CC node — we add up 
the cost of each G-marker used for each 
linearization, the pragmatic constraints 
assigned to each CSC node, and the prefer¬ 
ence for each CSC node. The hypothesis 
with the least cost will be selected as the 
translated result. 


Connectionist network. This network will 
be adopted with some computational costs. 
When a connectionist network is fully 
employed, every node in the network is 
connected with weighted links. A compet¬ 
itive excitation and inhibition process se¬ 
lects one hypothesis. Final interpretation 
and translation in the target language are 
selected by a winner-take-all mechanism. 

Modeling simultaneous interpretation. 

We developed the parallel incremental 
generation scheme to model simultaneous 
interpretation. In a practical deployment, 
real-time response will be an essential fac¬ 
tor. However, a traditional parse-and-gen- 
erate translation scheme inherently causes 
an unpleasant delay because the system 
must wait until the end of a sentence to 
begin translation. 

The length of an utterance varies accord¬ 
ing to the situation and the individual. 
Some of our corpora from actual simulta¬ 
neous interpretation sessions have a long 
average-utterance length of 15 seconds. 
One Japanese utterance, a single sentence, 
is 57 seconds long. While this seems too 
long for English speakers, it is conceivable 
for Japanese speakers. 

If we assume that each utterance is about 
15 seconds long, a speaker must wait more 
than 30 seconds to start hearing the trans¬ 
lation of his dialog partner’s response 
(Figure 18a). Even for dialogs with an 
average utterance length of five seconds 
(very short for Japanese dialogs), one 
transaction would require more than 10 
seconds. This presents a serious problem 
for practical systems, especially important 
if the utterances are long sentences con¬ 
taining several semantically separate parts, 
as is frequently observed when translating 
spoken Japanese into English. In such cas¬ 
es, simultaneous interpreters avoid un¬ 
pleasant delays by beginning translation 
before a whole sentence is spoken. We 
propose a simultaneous interpretation model 
that simulates human interpreters at work, 
beginning the translation before the end of 
sentence and thereby significantly reduc¬ 
ing transaction delay (Figure 18b). 

Figure 19 is a time-aligned transcript of 
English to Japanese simultaneous interpre¬ 
tation taken from a real translation session. 
E shows English sentences spoken by the 
speaker. J shows Japanese translation made 
by a simultaneous interpreter. The English 
annotations in e show translation timing. 
Note that the simultaneous interpreter starts 
translating before the utterance is com¬ 
plete. 

Table 1 shows a simultaneous interpre- 


46 


COMPUTER 
























tation attained with the bottom-up, incre¬ 
mental features in ODM-Dialog. Partial 
interpretations (concept fragments) of in¬ 
put utterances activate nodes in the 
memory network, which have links to the 
phrase and lexicon of the target language. 

The activation process for generation 
starts immediately, whenever a concept is 
activated during the parsing process, and 
triggers bottom-up passing of the markers 
involved in generation. There may be mul¬ 
tiple hypotheses for generation corre¬ 
sponding to multiple hypotheses for pars¬ 
ing, but only one hypothesis is selected 
for generation whenever a commitment 
to one best hypothesis is made at the 
parsing process. Then, verbalization is 
triggered. 

In Table 1, when the input word “I” is 
recognized, an A-marker is created and 
activates a CC node referring to “I.” This 
triggers creation of a G-marker at “watashi,” 
a Japanese word for “I.” Then, the G- 
marker is passed up to a CSC node repre¬ 
senting a syntactic pattern such as <*Actor 
*PP-HA> or <*Actor *PP-HA ♦Object- 
Event *PP-NI *Action *Modal>. When 
the next word “want” is recognized, “I” is 
determined to be an actor. This triggers 
verbalization of the CSC <*Actor *PP- 
HA>. Thus, the Japanese translation 
“Watashi ha” is produced. By the same 
token, translation of the first clause was 
triggered when meaning became unambig¬ 
uous as the speaker uttered “so.” The rest 
of the translation is made at the end of the 
input utterance because it cannot be disam¬ 
biguated until the end of the sentence. 

Figure 19. Transcript from actual simultaneous interpretation session. 

Prototype system 
results 

Integrating speech and natural lan¬ 
guage processing. It’s well known that 
syntactic and semantic levels of knowl¬ 
edge do not sufficiently constrain search 
space, and it’s hoped that the higher 
levels of constraint provided by prag¬ 
matic and discourse knowledge will help 
us reduce perplexity and thus attain 
higher recognition rates. In fact. Young’s 
group has attained very high semantic ac¬ 
curacy by introducing discourse know¬ 
ledge with a layering prediction method. 10 
The introduction of discourse knowledge 
would be useful for highly goal-oriented 
and relatively limited domains such as the 
Defense Advanced Research Project 
Agency resource management domain. 

But is this approach applicable to mixed- 


Table 1. Simultaneous interpretation in <I>DM-Dialog. 


Input Utterance 

Translation 


I 

want 

watashi ha (I Role-Agent. This is 

ellipsed in the actual translation 

attend 

the 

conference 

kaigi ni sanka shitainodesu (want 

to attend the conference) 

what 

sorede (so) 


I 

supposed 

do 

doushitara yoi deshouka (what an 

11 supposed to do) 


On behalf of the Financial Times, 

Financial Times sha wo daihyou itashimashite 
Financial Times Co. -ACC represent -HUMBLE 

may I welcome you all to the Imperial Hotel. 

minasamagata wo teikoku-hoteru ni 
you -PL -ACC the imperial hotel -LOC 

It is a great pleasure to see so many people 

gokangei itashimasu. Watashi ni torimashite 

welcome -HUM I for 

here today. 

minasanagata ni omenikakaruno ha kouei de arimasu. 
you -PL -DAT meet -HUM -TOP pleasure 


Our presentation today 


is in three parts 

Kyou no puresenteishon ha mittsu no bumon kara 
today -GEN presentation -TOP three -GEN part from 

First of all, I would like to give you a brief 

natteimasu Mazu saisho ni watakushi ga goku kantan ni 

consists first all, I -NOM briefly 

historical review of the Financial Times — 

Financial Times sha no rekishi ni tsuite no 
Financial Times Co. -gen history about -GEN 

where we are today, 

hanashi wo shimasu. Konnichi no genjou to 

talk -ACC -HUM today -GEN status and 

and what our plans are for the future. 

shourai no keikaku ga dounatte iruka no 
furture -GEN plans -TOP what status -GEN 


hanashi wo shimasu. 
talk -ACC -HUM 
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Related work 


Speech Trans, another prototype system developed at the Center for Ma¬ 
chine Translation at Carnegie Mellon University, uses a generalized LR parser 
extended to phoneme processing. 1 Speech Trans assumes noisy phoneme in¬ 
puts, similar to our system, and uses a confusion matrix to create hypotheses 
to correct possible phoneme-sequence errors. It uses a semantic-oriented 
grammar with a notation similar to Lexical Functional Grammar. Parsing results 
are represented in interlingua, a language-independent representation of mean¬ 
ing, and then sent to the generation module. Speech Trans translates Japa¬ 
nese utterances into English. The system operates on the doctor-patient do¬ 
main and handles such utterances as “Atamaga itai” (I have a headache). 

SL-Trans 2 is a prototype system derived from Japanese efforts at ATR Inter¬ 
preting Telephony Laboratories. SL-Trans employs HMM-LR parsing in which a 
Hidden Markov Model phoneme verifier provides probability measures to a pre¬ 
dictive LR parser. 12 The LR parser provides top-down constraints to phoneme 
recognition since the parser has an intraclause grammar (Bunsetsu Grammar). 
However, unlike <f>DM-Dialog or Speech Trans, the LR parser does not analyze 
sentence meaning. It is used only to provide correct word sequence hypothe¬ 
ses to a unification-based parser pipelined to the LR parser. The unification 
parser is based on a chart parser and employs Head-Driven Phrase Structure 
Grammar. By separating the parser for speech processing and semantic analy¬ 
sis, SL-Trans allows use of fully linguistic formalism in a straightforward man¬ 
ner, at the cost of redundancy (two independent parsing processes). Currently, 
SL-Trans translates spoken Japanese into English. It operates on the ATR con¬ 
ference registration domain. 


initiative dialogs with fairly wide domains? 

Our investigation of discourse-level 
predictions in the ATR conference regis¬ 
tration domain, a mixed-initiative domain 
that is less goal-oriented than DARPA’s, 
uncovered three basic problems. 

First, discourse knowledge did not sig¬ 
nificantly reduce perplexity in mixed- 
initiative dialog. Although using discourse 
knowledge generally helps reduce per¬ 
plexity, this assumes that dialog patterns, 
that is, transition patterns among subdo¬ 
mains, are relatively limited so that dis¬ 
course-level knowledge can further con¬ 
strain possible next word choice. In the 
ATR’s conference registration domain, 
there are many patterns of subtopic transi¬ 
tions. This makes it difficult to predict 
subdomain transitions. For example, we 
took 30 dialogs from the ATR corpus to 
measure the perplexity of subdomain tran¬ 
sitions. The total number of utterances was 
1,325, and we identified 31 subdomains 
and 177 transitions. Each subdomain con¬ 
tained several subdomains, but we did not 
count these details. We simply counted 
major transitions between relatively ab¬ 
stract subdomains. The number of utter¬ 
ances in each subdomain ranged from two 
to over 50. The perplexity of the test set 


without constraint was 4.95 (note that this 
is not a word choice perplexity, but a sub- 
domain choice perplexity). Using a bi¬ 
gram grammar at the subdomain transition 
level reduced perplexity to 3.44. Yet, on 
average, transition to a new subdomain 
requires selecting a domain from 11 hy¬ 
potheses. Since subdomains share consid¬ 
erable syntactic structure and vocabulary, 
reducing the next possible subdomain to 
one-third of all subdomains does not re¬ 
duce the possible next words to one-third. 
Therefore, unfortunately, we must con¬ 
clude that using discourse knowledge to 
capture transition patterns among subdia¬ 
log domains would have only a limited 
impact in reducing perplexity in mixed- 
initiative domains with larger topic space. 

Second, the nature of mixed-initiative 
dialog makes accurate prediction even more 
difficult. Unlike the DARPA resource 
management domain, the ATR domain is a 
mixed-initiative dialog where the two par¬ 
ticipants have their own intentions and 
goals. Here is an example taken from the 
ATR corpus: 

Secretary : Please give me your card 
name and number. 

Questioner: It’s American Express, the 


number is 123-45678-90123. Will the pro¬ 
ceedings be published? 

Secretary: Yes, it will be published in 
July. Can I charge a registration fee to your 
AMEX account? 

Questioner: Yes, and send me a registra¬ 
tion form please. 

Secretary: OK. I need your full name 
and phone number, too. 

The domain of this subdialog seems to 
be a credit card charge, but it has subdia¬ 
logs about the proceedings registration form. 
Speech acts may be predictable, since more 
than 80 percent of the interaction is based 
on the request-inform interaction plan, but 
predicting which subdomain the dialog may 
switch to — and when — is hopelessly 
difficult. In the middle of a dialog about a 
credit card, how can we predict that the 
questioner may ask if the proceeding will 
be published? We therefore conclude that 
although stronger preferences can be placed 
on some subdomains, the system must be 
able to expand its search space to nearly the 
entire domain to handle sudden switching 
of subdomains in complicated dialog 
structures. This would drastically increase 
the perplexity measure. In the case of our 
experimental set, it should fall somewhere 
between 2.4 and 19.7. However, expand¬ 
ing the search space to the entire domain 
significantly undermines the recognition 
rate. We still do not have an answer to this 
problem. 

Third, prediction failures can undermine 
recognition rates by pruning out a correct 
hypothesis in favor of an incorrect but 
predicted hypothesis. The odds of making 
wrong predictions depend on the coverage 
of the corpus collected from real dialogs. If 
the corpus covers a sufficient portion of 
possible dialog transitions, the chances of 
making wrong predictions will be low. In 
the ATR’s conference registration domain, 
which involves various topics such as 
sightseeing, dinner, and hotel reservations, 
covering all possible subdomains and tran¬ 
sitions is nearly impossible. While cover¬ 
ing all possible transitions is not feasible, 
the problem remains of how to avoid se¬ 
lecting wrong but predicted hypotheses 
when an unexpected utterance is made. We 
believe that higher level knowledge can 
help only a little and can even be harmful. 
The only solution, we suggest, is to im¬ 
prove speech recognition at lower levels. 

Commitment and ambiguities. Devel¬ 
oping an incremental disambiguation 
scheme, one that effectively eliminates 
implausible or impossible interpretation. 


COMPUTER 








is essential for a simultaneous interpreta¬ 
tion system. To overcome transaction de¬ 
lay, we introduced the simultaneous inter¬ 
pretation model so that translation can begin 
before completion of sentence parsing. The 
premise is that, in a long utterance, the 
input sentence can be disambiguated at a 
reasonable point. If an input utterance is 
totally ambiguous until the end of the sen¬ 
tence, translation cannot begin because its 
meaning cannot be determined. This is a 
very severe premise considering the extra 
ambiguities added by the multiple hypoth¬ 
eses produced by the speech processing 
module. Although the input sentence does 
not need to be fully disambiguated to start 
translation (because some part of the sen¬ 
tence can be translated without risking 
mistranslation regardless of how the rest of 
sentence is analyzed), full disambiguation 
at the earliest point is desired. This require¬ 
ment can be met only by an incremental 
disambiguation scheme that prunes out less 
probable or impossible interpretations upon 
detection. This requires world knowledge 
and a strong top-down expectation of what 
can be uttered next. Although predicting 
the next subdomain has proven to be highly 
difficult, we have observed that more than 
80 percent of the utterances involved inter¬ 
actions called request-inform interaction 
plans. (How much is the registration fee? It 
is 100 dollars.) While spoken dialog has a 
less complicated syntactic structure than 
written text, high predictability of the type 
of utterance at the pragmatic level would 
help disambiguation at an early stage of 
processing. 

Performance and implementation. The 

demonstration version of ®DM-Dialog 
translates a short spoken sentence in three 
to 10 seconds, but this speed and success 
rate is attained within a very small vocab¬ 
ulary size and is expected to degrade as the 
system scales up. The current system has a 
vocabulary of less than 100 words and a 
network of less than 1,000 concept nodes. 
A scaled-up version has a 350-word Japa¬ 
nese vocabulary and a 450-word English 
vocabulary, but it requires a longer pro¬ 
cessing time. We need substantial counter¬ 
measures to improve performance. 

We have implemented our model on two 
massively parallel machines: the IXM2 7 
and the SNAP. 8 The IXM2 is an associative 
parallel machine with 64 associative pro¬ 
cessors and nine network processors; it 
attains 7,200 million operations per 
second for less-than operations with 256K 
parallelism. The IXM2 supports the parallel 
marker-passing scheme from the hard- 
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ware level. By taking full advantage of 
the hardware’s parallelism, we expect to 
circumvent major performance bottle¬ 
necks. 

The results of preliminary experiments 
on the IXM2 are promising. The advantag¬ 
es of the massively parallel approach were 
demonstrated by a series of experiments 
using the IXM2, Sun-4, and Cray X-MP. 
While the IXM2 completes a syntactic 
analysis in less than 1.3 milliseconds for 
sentences averaging eight words in length, 
the Sun-4/330 with optimized C coding 
took over 18 milliseconds. The Cray X- 
MP took over 20 milliseconds due to its 
subrouting call overhead. We expect fur¬ 
ther scale-up and incorporation of semantic 
interpretation to demonstrate the benefits 
of our approach. Since the IXM2 propa¬ 
gates markers in parallel, scaling up the 
memory network does not cause an expo¬ 
nential explosion in search time. Current¬ 
ly, we have installed over 2,000 syntactic 
patterns on the IXM2, and it can load over 
30,000 syntactic patterns. The high-densi¬ 
ty associative memory permits scaling up 
to 100,000 patterns, but some problems 
remain. The amount of data that can be 
passed with minimum performance deg¬ 
radation is severely limited. Thus, for the 
IXM2 implementation, we had to separate 
the memory network search and the infor¬ 
mation build-up process in our model. 
Marker propagations are carried out on the 
associative memory, taking advantage of 
the 256K parallelism and the constraint 
check, and 64 transputers carry out the 
buildup of meaning representations. 

On SNAP, which supports parallel 
marker passing from the hardware level, 
we not only use bit markers but also address 
and value markers. Augmenting the infor¬ 
mation on markers significantly expands 
SNAP’s ability to handle the complex pro¬ 
cessing most AI applications require. 
SNAP, one of the most powerful semantic 
network processors ever developed, uses 
160 Texas Instruments TMS320C30 DSP 
chips organized into 32 tightly coupled 
clusters connected by a modified hyper¬ 
cube. The current design of SNAP handles 
16K nodes and 160K connections, and 
there are plans for a VLSI version that can 
handle more than a million nodes. The 
SNAP implementation is closer to the 
original system than the IXM2 version 
because SNAP can propagate bit markers, 
pointers, and probabilistic values. In our 
experiments, the SNAP version translated 
at a promising rate (a few milliseconds), 
and we are currently scaling up to large- 
vocabulary size. 


T he utility of the prototype system is 
that it illustrates the advantages 
and disadvantages of our approach 
and reveals problems with which we must 
deal in the next stage. The next step is to 
develop a scaled-up system based on these 
findings and to field test it in a well-de¬ 
fined, relatively small domain. Such a 
system will require extensive collabora¬ 
tion among linguists and computer scien¬ 
tists, as well as international collaboration 
involving the United States, Japan, and 
other countries. 

We hope to report about a scaled-up 
system — one that can actually be de¬ 
ployed, although in a restricted domain — 
by the end of this century. ■ 
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The Literate-Programming 
Paradigm 


David Cordes and Marcus Brown 
University of Alabama 


T he ability to comprehend a pro¬ 
gram written by other individuals 
is becoming increasingly impor¬ 
tant in software development. Given that 
the general cost of program maintenance 
may reach 60 percent of the total software 
costs associated with a certain product, 1 a 
real demand exists for systems that can 
present the program text in a readable, 
understandable format. Comprehension of 
another individual’s program should be 
made as simple as possible. Therefore, 
methods that promote program compre¬ 
hension should be encouraged. 

Donald Knuth introduced the concept of 
literate programming as a method to im¬ 
prove the quality of computer software. 2 
One of the chief goals of literate pro¬ 
gramming is to present a technique for 
coding software systems that promotes 
readability and comprehension. Realizing 
that these programs must be read and main¬ 
tained by others, we draw an analogy to the 
writing of a book or an essay. Since the 
programmer is essentially providing a work 
of literature to be read by others, this tech¬ 
nique for program coding has become 
known as literate programming. 

In this article, we examine this paradigm 
in detail, first reviewing the current liter¬ 
ate-programming paradigm with two sam- 
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Literate programming 
presents a tool for 
constructing readable, 
understandable, and 
maintainable code. We 
review this paradigm, 
analyze its strengths 
and weaknesses, and 
present some 
enhancements. 


pie literate programs, next presenting a 
critique of literate programming as it is 
currently used, and then exploring meth¬ 
ods for enhancing the process. We propose 
a number of new facilities and present 
restrictions on current literate-programming 
practices. 

0018-9162/9l/0600-0052$01.00 © 1991 IEEE 


The literate paradigm 

Computer scientists have always targeted 
computer programs for specific audiences, 
employing compilers that will accept spe¬ 
cific code and convert it to sets of instruc¬ 
tions that can be carried out on hardware. 
However, these programs have been writ¬ 
ten by humans, tested and debugged by 
humans, and maintained by humans. If 
humans thought and acted like computer 
hardware, this scenario would pose no 
problems; programmers and hardware, 
operating in a similar manner, could take a 
programming language designed for either 
of them and function equally well. 

However, that is not the case. The orga¬ 
nizational and structuring techniques that 
express actions to a piece of hardware in a 
programming language are not necessarily 
the same techniques used when expressing 
these ideas to a group of programmers. We 
find that today’s programming languages 
target one of these two groups, the hard¬ 
ware, at the expense of the other, the pro¬ 
grammers. 

This is not to say that current program¬ 
ming languages are inappropriate for the 
programming community. Structured pro¬ 
gramming constructs, high-level lan- 

COMPUTER 












guages, and proper indentation style can 
significantly improve the readability and 
comprehension of a program. However, the 
fact remains that programmers primarily 
construct given programs for compilation 
and give little regard to organization and 
management of the thought processes that 
represent the logic of the programs. They 
generally keep such information in auxilia¬ 
ry documents, if it is generated at all. 

The literate paradigm recognizes that 
different audiences — other programmers 
and a compiler — will receive this pro¬ 
gram. To address these audiences, the 
program must be processed in two different 
paths, as Figure 1 shows. For the human 
audience, the source code is processed by 
Weave, producing a document for typeset¬ 
ting. For the computer, the source is pro¬ 
cessed by Tangle, producing a program in 
the underlying source code (for example, 
Pascal, C, or Fortran) suitable for the 
compiler in a format that is basically un¬ 
readable by a human. 

A typical literate source program is nor¬ 
mally referred to as a web. The file name 
that contains the program usually includes 
.web as its suffix. The use of the term web 
illustrates the complex structures within 
the underlying program. This web can ei¬ 
ther be woven into a document or tangled 
into a machine-readable object file. 

Figure 1 illustrates one very important 
point regarding the literate paradigm. When 
you program in a literate environment, you 
write in multiple languages at the same 
time. First, you enter statements in a con¬ 
ventional programming language; these are 
the statements that will be compiled. Sec¬ 
ond, you generate a description of the pro¬ 
gram using a word processing language. 
This text will explain your actions to others 
who read the program. Finally, a set of 
commands is required to link the program¬ 
ming language statements and word pro¬ 
cessing statements into a coherent docu- 


The Web literate-programming lan¬ 
guage. Knuth developed the Web system 
as a working literate-programming language. 
The system has been used for small and 
large programs. 3 For example, the Tex 
typesetting system is written in the Web 
programming language. In each case, the 
primary goal has been to write the program 
for reader comprehension. Originally cre¬ 
ated for the Pascal language, Web has since 
been adapted to C, 4 Fortran, 5 Ada, and 
other programming languages. 6 

As with any other literate language, the 
Web source file consists of statements in 




Word processor 


Weave__^_ 

_ ^ myfile.txt 


->- Typeset listing 

myfile.web 


Compiler 


Tangle 

myfile.src 


Compiled program 


Figure 1. Processing a literate program. 


Unnamed module Named modules 



Figure 2. Program composition via modules. 


three distinct languages: a programming 
language, a word processing language, and 
literate (in this case, Web) commands. The 
literate command set is used to organize 
and manage the code and documentation 
associated with a literate program. 

The literate program is composed of a 
set of modules, each generally identified 
by a unique name. This name is entirely 
optional, although supplying most modules 
in a literate program with a name is com¬ 
mon practice. A module in a literate program 
is designed to convey one thought or idea 
within the overall program logic. 

While assigning names to a module is 
recommended, at least one module in the 
program doesn’t have a name. This module 
functions as an anchor around which the 
rest of the modules are positioned, as Figure 
2 shows. This permits abstraction of the 
basic thoughts regarding program logic 
into a sequence of lower level ideas and 
actions, thus capturing the process of 
stepwise refinement for the algorithm. 

Using these modules allows the literate 
program to be expressed in a way not avail¬ 
able to conventional structured program¬ 
ming languages. As Figure 2 shows, named 
modules are pulled into the program as 


demanded by the root (unnamed) module. 
However, their place in the actual text of 
the Web program is completely arbitrary. 
The program author can place these mod¬ 
ules as deemed appropriate. 

This ordering is expected to convey the 
activities of the program in an organized 
manner. Freed from constraints regarding 
management and organization during pro¬ 
gram construction, the author can present 
these ideas in an order believed to maximize 
program readability and comprehension. 

Examining a literate program in greater 
detail reveals that all modules contain three 
distinct parts: documentation, definitions, 
and code. Each part is optional, and a given 
module might contain any or all of them. 
The only restriction is that the parts must 
appear in the order listed above. 

A description of the functions and ser¬ 
vices performed by a given module is kept 
in the documentation section, written in 
word processor-like fashion. The author is 
expected to use these facilities, embedding 
text-processing commands into the text. 
After processing with Weave, the text is 
presented in a readable format. 

This section is designed to be written in 
parallel with the code contained in the 
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@u 

signals the start of a new module (u represents a space) 

@* 

signals the start of a new module that is a section header; 
all section headers appear in the program listing’s table 
of contents 

@d 

signals the start of a definitions section 

@c 

signals the start of code in an unnamed module 

@< 

signals the start of a module name 

@> 

signals the end of a module name 

@<name@> = code 

associates code with the module specified 

@<name@> + = code 

appends more code to the end of the module specified 

lexprl 

word processing command, formats contents like code listing 


Figure 3. Basic Web command set. 


module. By identifying a location for doc¬ 
umentation to be placed in the module, the 
designers of the literate paradigm hoped to 
increase the use of documentation by the 
application programmers. Instead of being 
appended as extra information to the pro¬ 
gram, documentation is thus viewed as an 
integral part of the program. Its omission, 
rather than its inclusion, is what is most 
noticeable. 

The definitions section supports macro 
definitions that can be either simple mac¬ 
ros that define user-oriented mnemonics 
for standard programming language con¬ 
ventions or single-parameter macros. 

With one exception, the code section 
simply contains programming language 


statements in the language being used to 
generate the program. The code may in¬ 
clude (at any point) the name of another 
module within the program. As Figure 2 
shows, the code from any named module 
referenced within the current module is 
included in the current module’s code. 

Two sample Web programs. Next, we 
develop two sample programs using the 
Web programming language. The first 
program is a reproduction of the famous 
Hello World program seen in textbooks. 
The second program computes the first 25 
Fibonacci numbers. 

We will develop these programs using 
the literate-programming language CWeb. 4 


Web files generated using CWeb rely on 
Tex for word processing and the C pro¬ 
gramming language to generate the actual 
code. For each of these programs, we present 
the initial Web source code, the woven 
typeset document, and the tangled pro¬ 
gramming language code. The Web lan¬ 
guage is the literate language used. Figure 
3 contains a listing of the Web commands 
used to compose these programs and should 
serve as a reference for reading the original 
source code. 

The first program, Hello World, is a 
trivial piece of code to implement. The 
example is presented solely to introduce a 
number of the concepts inherent to literate 
programming. Figure 4 shows the actual 
CWeb code for this program. 

When a literate program is woven, a 
table of contents is automatically generated 
for the program. Any module in the literate 
program identified as a section header is 
listed in the table of contents by its number; 
the page where it’s found is also listed in 
the table of contents. 

Identification of modules that function 
as section headers depends on the program 
author. The author must identify the modules 
that logically define the structure of the 
developed program by introducing the 
module with a @*, as opposed to the stan¬ 
dard @ U ( U represents a blank). The 
string following @* represents the section 
header and ends with a period. Except for 
this introduction, no differences in appear¬ 
ance or content exist between a module 
that functions as a section header and any 
other module in the program. The section 
headers simply identify the logical sections 
of the program. 

The program index is also generated 
during literate-program weaving. The in¬ 
dex captures all variable names, function 
names, and procedure names in one concise 
index. It indicates both the declaration and 
use of these elements throughout the pro¬ 
gram. 

The declaration of a variable or function 
causes the associated entry to be underlined. 
All references to the variable are simply 
listed in the index. Additional entries, gen¬ 
erated as the author desires, can be added. 
Finally, a second index is generated con¬ 
sisting of the module names used within 
the program. 

Running Weave on the Hello World 
program generates the output shown in 
Figure 5. A horizontal line separates each 
page of the actual output in the figure. 

While the woven output from Tex is a 
readable document, the tangled C code 
generated from the Hello World program is 


@* Hello World program. 

This is a small demonstration of the use of Web in a program that prints the 
famous Hello World greeting. 

@ Main program. 

This is the unnamed code module to which all other modules connect. 

@c 

@<Include files@> 
main() 

{ 

@<Print greeting @> 

} 

@ Include files. 

The only include file required is Istdio.hl. 

@<Include Files@> = 

#include <stdio.h> 

@ Issue the actual print statement. 

@<Print greeting@> = 
printf(“hello worldXn”); 


Figure 4. Hello World program text. 
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not. Figure 6 illustrates the output generat¬ 
ed from a tangled CWeb program. As you 
can see by examination, this output is not 
designed for human comprehension. 
However, a standard C compiler can func¬ 
tion very well with this input. The com¬ 
ments that exist in the code refer to the 
number of the module responsible for gen¬ 
erating those lines. 

Next, we present the second example, a 
program designed to generate the first 25 
Fibonacci numbers in its woven form (us¬ 
ing Tex) and without any other introduc¬ 
tion. In the belief that this format proves 
readable without further explanation, we 
suggest scanning through the program, as 
shown in Figure 7, and analyzing the read¬ 
ability of this document. Figure 8 shows 
the actual CWeb file that generated the 
document. 


Critique of literate 
programming 


To date, the programming community 
hasn’t widely accepted the use of literate¬ 
programming languages for a number of 
reasons. The majority of the arguments 
revolve around the lack of integration of 
the literate paradigm into the conventional 
software development life cycle and the 
current environment supporting literate 
programming. 

The literate paradigm and the soft¬ 
ware life cycle. Literate programming 
provides a technique for program develop¬ 
ment that represents partial covering of the 
overall software development life cycle. 
Figure 9 indicates the actual part of the life 
cycle covered by the literate paradigm. 
When reviewing the life-cycle processes, 
it becomes apparent that literate program¬ 
ming is essentially a technique to be used 
for system implementation. The current 
literate paradigm concentrates on the de¬ 
velopment and documentation of the actual 
system code. In addition, the literate para¬ 
digm claims benefits in the life cycle’s 
final stage, that of maintenance. 2 

In itself, the literate paradigm does not 
offer a complete mechanism for software 
development. Such development must be 
provided with the proposed system’s spec¬ 
ification and high-level design. This input 
is normally expressed using conventional 
specification and design strategies, such as 
structured design or object-based tech¬ 
niques. 

This is the data that provides the func¬ 


Table of Contents 

Hello World program.Section 1, Page 1 


Source Code 

1. Hello World program. This is a small demonstration of the use of Web in a 
program that prints the famous Hello World greeting. 

2. Main program. This is the unnamed module to which all other modules 
connect. 

(Include files 3 ) 
main () 

{ 

(Print greeting 4 ) 

} 

3. Include files. The only include file required is stdio.h. 

( Include files 3 ) m 

#include <stdio.h> 

4. Issue the actual print statement. 

( Print greeting 4 ) 

printj {{“hello world\n”); 

This code is used in section 2. 


Variable Index 

main : 2. 
printf : 4. 


Section Index 

( Include Files 3 ) Used in section 2. 

( Print Greeting 4 ) used in section 2. 


Figure 5. Document generated from Weave for Hello World. 


tionality and design necessary to guide the 
construction of a literate program. However, 
most of the literate examples to date 7 have 
minimized the use of formalized specifi¬ 
cation and design strategies as a necessary 
prerequisite for literate programming. 

The projects illustrated do not properly 
emphasize the importance of either the 
system specification or system design. The 
literate paradigm does not explicitly pro¬ 
vide for the development of either func¬ 
tional system specifications or high-level 
design plans. 

Additionally, the literate paradigm pro¬ 
vides no guidelines for establishing a set of 
testing criteria. The ability to test the im¬ 
plemented software product is of para¬ 
mount importance to the developmental 
process; yet, testing remains an ill-defined, 
user-oriented function within the literate 


1*2:*/ 

#line 11 “hello, web” 
1*3:*I 

#line 23 “hello.web” 

#include<stdio.h> 

/*:3*/ 

#line 12 “hello.web” 
main() 

{ 

/*4:*/ 

#line 27 “hello.web” 
printf(“hello world\n”); 
/*:4*l 

#line 16 “hello.web” 

} 

l*:2*l 


Figure 6. C program generated from 
Tangle for Hello World. 
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1. Fibonacci numbers. 

Program to compute the first 25 Fibonacci numbers. 

2. Main program. 

This is a skeletal program body around which the program 
is constructed. We define the constant MAX as 25 in the 
definitions section. 

#define MAX 25 
(Include files 3 ) 
main () 

{ 

(Main variable declarations ) 

(Generate Fibonacci) 

} 


3. Include files. 

The only required include file is stdio.h. 
(Include files) = 

#include <stdio.h> 


Thisc 


4. Local (main) variables. 

Here are our local variables for the routine main. Right now 
we know we need a counter to count the first 25 
Fibonacci numbers. 

( Main variable declarations ) = 
int count; 

See also section 5. 


5. Generation of Fibonacci numbers. 

This requires an initial priming with two values. The first 
two values are zero and one, respectively. After this, the 
next value is computed by fib n = fib„ _ t +fib B _ 2 . So, we need 
variables to keep the last two values and the computed value. 

( Main variable declarations ) + a 
int fibl - 0 ,fib2 = 1, newfib; 

6. Generation of Fibonacci numbers. 

The count of numbers generated is started at two. We will 
print a title and the first two numbers, and then loop until 
we have generated 23 additional numbers. 

( Generate Fibonacci ) a 
( Print titles and first two ) 
count = 2; 


( Loop to Print Remainder ) 


7. Printing titles. 

The program will double space before the title, print a 
heading, and then output the first two Fibonacci numbers. 

( Print titles and first two ) a 
printf (“Fibonacci numbers”); 
print/ (“%d”, fibl)-, 
printf (“%d”, fibl)-, 


8. Generate the remainder of the list. 

The loop will run until count has a value greater than 25. 
For each pass through the loop, a new value is generated 
and then the previous two values are reset for the next 
pass of the loop. 

( Loop to print remainder) a 
While (count) < MAX) { 

( Compute new Fibonacci ) 
printf (“%d”, newfib )-,) 

( Reset last two Fibonacci values ) 
count - count + 1; 


9. Computing the next Fibonacci. 

The formula, as given above, is fibn = fibn - 1 +fibn - 2. 
( Compute new Fibonacci) a 
newfib = fibl +fib2: 


10. Reset the last two values. 

( Reset last two Fibonacci values > a 
fibl =fib2; 
fib2 = newfib-. 


Variable Index 

count : 4, 6, 8. 
fibl: 5, 7, 9, 10. 
fibl: 5, 7, 9, 10. 
main: 2, 4. 

MAX: 2, 8. 
newfib: 5, 8, 9, 10. 
printf: 7, 8. 
stdio: 3. 


Section Index 

( Compute new Fibonacci 9 ) used in section 8 
( Generate Fibonacci 6 ) used in section 2. 

( Include files 3 ) Used in section 2. 

( Loop to print remainder 8 ) used in section 6. 
( Main variable declarations 4, 5 ) used in se 
( Print titles and first two 7 ) used in section 6. 
( Reset last two Fibonacci values 10) used 


Figure 7. The woven output for the Fibonacci program. 
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@* Fibonacci numbers. 

have generated 23 additional numbers. 

Program to compute the first 25 Fibonacci numbers. 

@<Generate Fibonacci @> = 

@* Main program. 

@<Print titles and first two@> 
count = 2; 

This is a skeletal program body around which the program is 

@<Loop to print remainder @> 

constructed. We define the constant IMAXI as 25 in the 

definitions section. 

@* Printing titles. 

@d 

Double space before the title, print a heading, and then 

MAX 25 

output the first two Fibonacci numbers. 

@c 

@<Print titles and first two@> = 

@<Include files@> 

printf(“\n\nFibonacci numbers\n”); 

main() 

printf(“\n\t%d\n”, fibl); 

( 

printf(“\t%d\n”, fib2); 

@<Main variable declarations @> 

@<Generate Fibonacci @> 

@* Generate the remainder of the list. 

) 

@ The only required include file is Istdio.hl. 

The loop will run until Icountl has a value greater than 25. 

For each pass through the loop, a new value is generated 

@<Include files @> = 

and then the previous two values are updated for the next 

#include <stdio.h> 

pass of the loop. 

@* Local (main) variables. 

@<Loop to print remainder @> = 
while ( count < MAX ) { 

Right now, we know we need a counter to count the first 25 
numbers. 

@<Main variable declarations @> = 

@<Compute new Fibonacci @> 

printf(“\t\%d\n”, newfib); 


@<Update last two Fibonacci values@> 

@ Generation of Fibonacci numbers requires an initial 

count = count + 1; 

} 

priming with two values. The first two values are zero and 

one, respectively. After this, the next value is computed 

@* Computing the next Fibonacci. 

by $fib_n = fib_{n - 1} + fib_{n - 2}$. 

The formula for computing the next Fibonacci number is 

So we need variables for the last two values and the 

$fib_n = fib_{n - 1} + fib_{n - 2}$. 

computed value. 

@<Compute new Fibonacci @> = 

@<Main variable declarations @> + = 

newfib = fibl + fib2; 

int fibl = 0, fib2 = 1, newfib; 

@* Generation of Fibonacci numbers. 

@* Reset the last two values. 

@<Reset last two Fibonacci values @> = 

The count of numbers generated starts at two. We print a 

fibl = fib2; 

title and the first two numbers, and then loop until we 

fib2 = newfib; 


Figure 8. Fibonacci program. 


Specification 

Design 

Implementation 

Testing 

Maintenance 



| ??? | 



Figure 9. Life-cycle coverage offered by the literate paradigm. 


world. Due to differences in both program 
organization and presentation, a different 
approach is often required when debug¬ 
ging literate programs. 

While the current literate paradigm hasn’t 
been integrated into the software develop¬ 
ment life cycle, recent research has shown 
the ability to merge literate programming 
with the design process. 8 This research has 
demonstrated that literate programs pro¬ 
vide a strong bridge between low-level 
system design and system implementation. 9 
In addition, the enhancements set forth in 
the “Enhancing the paradigm” section 
permit further integration with the existing 
software life cycle. 


The elitism of literate programming. 

The literate paradigm has also suffered 
from its own claims. As suggested by its 
founder, literate-programming languages 


are not suitable for everybody. Knuth ar¬ 
gued that a literate-programming-language 
user must “be comfortable dealing with 
several languages simultaneously.” 2 
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Figure 10. Single level vs. multilevel 
table of contents. 


Specifically, the user must not only know 
the underlying implementation language, 
but also a word processing language, a 
literate-programming language, and the 
possible interactions of all three. This im¬ 
plies that errors from a variety of languag¬ 
es may now appear within a single pro¬ 
gram. Knuth hoped that computer scientists 
(as opposed to programmers) will have a 
greater desire to communicate the essen¬ 
tials of a program to others and, therefore, 
be more disposed to literate programming. 

While not intended to impede the devel¬ 
opment of a literate-programming commu¬ 
nity, this argument has essentially restrict¬ 
ed the concept of literate programming to 
the academic community. Although it has 
been adopted for use in some organizations, 
this tends to be the exception rather than the 
rule in a nonacademic environment. 

The benefits of literate programming. 

Despite the drawbacks listed above, the 
literate paradigm provides exactly the fea¬ 
tures and tools demanded in large-scale 
software engineering projects. In fact, we 
believe that the concepts inherent to the 
literate paradigm should be used in all 
large-scale software development projects. 

To effectively manage the information 
associated with program development, the 
program author should have all necessary 
data regarding the problem at hand. This 
includes domain knowledge, relevant pro¬ 
gramming techniques, and prior program¬ 
ming language expertise. Lacking any of 
this will impede the development of qual¬ 
ity software products. 

The literate paradigm permits the pro¬ 
gram author to organize and manage the 
logic of the program being developed as 
appropriate. The structure of the developed 
program can thus mirror the author’s men¬ 
tal image of the program and its associated 


processes. The author can group and orga¬ 
nize the program’s concepts and character¬ 
istics in a manner designed to promote 
readability and understandability. 

Literate programming demands the gen¬ 
eration of system documentation in paral¬ 
lel with system composition. The reason a 
software engineer can’t provide this doc¬ 
umentation isn’t from a lack of text¬ 
processing skills (most software engineers 
are well versed in both programming and 
text processing languages), but because of 
the author’s inability to properly organize 
and document his or her thoughts. 

However, the argument remains regard¬ 
ing whether or not proper code documen¬ 
tation can be achieved by merely adding a 
specific section of each module to hold this 
documentation. As mentioned previously, 
any section of the module can be omitted 
by the program author. 

Is it possible to generate literate programs 
devoid of documentation? Unfortunately, 
the answer to this query is yes. Most advo¬ 
cates of literate programming claim that 
they feel a moral obligation to document 
literate code and do not experience a sim¬ 
ilar feeling when programming in a con¬ 
ventional language. Nevertheless, no em¬ 
pirical study exists that demonstrates 
documentation does indeed improve in a 
literate environment. 

Brook’s Law 10 shows that the limiting 
factor in large software projects has 
stemmed more from communication limi¬ 
tations between programmers than from 
the difficulty of the programming itself. 
The literate paradigm’s encouragement of 
programs written to be understood by others 
should ease these communication limita- 

In most professions, the individuals who 
inspire the most confidence are those who 
can not only perform their assigned duties, 
but who can also explain what has hap¬ 
pened in a clear, concise manner. 

Perhaps the best analogy for the claim 
that the software engineer must be able to 
properly organize and manage the con¬ 
cepts associated with a given software 
project is as follows: If you are taking a 
class on ancient civilization and are absent 
with illness one day, you will need to see 
someone else’s notes. You would prefer to 
see a set of notes in which the organization 
and content of the lecture are clearly ex¬ 
pressed. 

The same holds true for software de¬ 
velopment. You want a piece of code that 
tells you what it does and presents infor¬ 
mation in a simple, organized manner. The 
software author should not only possess 


the ability to generate code but provide a 
structure and organization to that code. 

Enhancing the 
paradigm 

Given the strengths and weaknesses of 
current literate programming, a number of 
modifications must be made to enhance its 
potential use as a practical software coding 
strategy. The next two sections specifically 
deal with a set of features we propose 
should be added and several features that 
should be removed. 

Additional items demanded by the 
paradigm. We propose adding four items 
to the literate paradigm to improve the 
usability and presentation of literate pro¬ 
grams. They are a multilevel table of con¬ 
tents, a graphical user interface, program 
debugging tools, and an enhanced index. 

These four items are designed to assist in 
the development, debugging, and mainte¬ 
nance of literate programs. We developed 
the graphical interface and debugging tools, 
and are currently developing the multilevel 
table of contents and enhanced index. The 
graphical interface supports an X Windows- 
based programming environment. The de¬ 
bugging tools operate within an Emacs- 
style editing environment. 

Multilevel table of contents. We propose 
a substantial restructuring of the table of 
contents. Currently, all modules that 
function as section headers (designated by 
the programmer) are automatically included 
in the program table of contents, as illus¬ 
trated in Figures 5 and 7. Web automatically 
generates the numbering and page numbers 
for these modules. However, the table of 
contents format is a single-level structure, 
resembling the chapters of a novel. The 
literate paradigm would benefit through 
the use of a multilevel table of contents, as 
is used in textbooks. Figure 10 illustrates 
the benefits of such a multilevel table of 
contents, using the Fibonacci program in¬ 
troduced previously. 

A multilevel table of contents provides a 
more accurate reflection of the author’s 
desired structure and organization of in¬ 
formation within the program. Current lit¬ 
erate-programming languages have strug¬ 
gled with the identification of section 
headers, since all headers appear to be 
equal entities within the table of contents. 
By defining a logical hierarchy for these 
section headers, a more readable and un- 
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Foo() 

{ 

.... < 6 statements >.... 

While (Index < Max) { 

i 

.... < 3 statements >.... 
i | If (sum > 0) { 

1 i 

1 ' i 

i .... < 2 statements > .... 

i [ | You are here 


Figure 11. The scope of a sample module. 


derstandable program overview is presented 
within the table of contents. 

Graphical user interface. Writing a lit¬ 
erate program requires using the set of 
Web commands that govern the scope of 
modules, the relationship between modules, 
indices, typesetting commands, and a va¬ 
riety of other matters. By presenting an 
interactive graphical interface to program 
construction, a number of Web commands 
can be performed automatically through 
the use of windowing and mouse selection. 

Marcus Brown developed an interactive 
environment for literate programming and 
tested a prototype. Programmers using this 
type of window-based environment could 
work with Web code without having to 
know the Web commands. Initial studies 
using a prototype of the environment show 
a strong preference for the graphical inter¬ 
face over other current interfaces (p < 0.01). 11 

As Knuth argues, the combination of 
programming language commands, type¬ 
setting commands, and Web commands 
produces a complex environment in which 
the programmer is required to work. The 
graphical interface clearly separates the 
Web commands from the programming 
and typesetting commands, and visually 
delineates modules and parts of modules. 
The use of a different input device for the 
Web commands (for example, the mouse) 
permits the programmer to physically as 
well as mentally separate these functions 
from those of coding and typesetting. 

Program debugging tools. A set of 
graphical tools for assisting in program 
development and debugging should be 
available to the literate-programming 
community. These tools not only serve the 
author in writing the program, but they also 
assist in debugging and maintaining liter¬ 
ate programs. 

Two tools have been developed to assist 
the programmer in understanding the 
structure of the overall program. The first 
tool, called Cnest, illustrates the location 
and nesting level of the current module 
within the overall scope of the actual pro¬ 
gram code. The second tool, called Cscope, 
displays the overall program and the 
modules that constitute the program. Both 
tools provide information regarding the 
physical structure of the program under 
construction. 

Cnest, illustrating the nesting level and 
scope of the current module, is primarily 
designed for the program author. The 
module in question is placed in its proper 
perspective relative to the overall program. 


MakeString() 

defined in module 13 
contains no other modules 
InOrderTraversef ) 
defined in module 34 
contains no other modules 
PreOrderTraverse( ) 
defined in module 35 
contains no other modules 
PostOrderTraversei ) 
defined in module 36 
contains no other modules 
main( ) 

defined in module 2 
contains modules 3, 4, 5, 6, 7, 15 


Figure 12. The structure of a literate 
program (Tree-traversal program). 


Figure 11 gives a sample of the output 
from this tool. 

Cscope enables readers versed in con¬ 
ventional programming languages to see a 
literate program in a more familiar setting. 
This view of the overall structure of the 
underlying program is useful during debug¬ 
ging and maintenance. Figure 12 identifies 
the general outline of the complete program. 
The association of modules with functions 
is needed to perform literate-program runtime 
debugging. Once the function in question is 
isolated, the modules that compose that 
function can be analyzed. 

Enhanced index. The index to a literate 
program provides the author and reader 


Identifiers and Author-Generated 
Entries 

Identifiers (constants, variables, 
procedures, functions) 
sections in which it appears 
sections defining it 
only definitions for single-letter 
identifiers 

Author-generated entries 
system dependencies 
key program topics 
other author notes 


Module Index 

Modules 

module name and section number 
list of modules referencing it 


Figure 13. Items currently found in a 
program index. 


with a standard set of information regard¬ 
ing the specific location of items within the 
program. As illustrated in Figure 13, Knuth 
identified a set of entities that belong with 
a program index. The current index format 
places all variable declarations and refer¬ 
ences, as well as the author’s hand-coded 
entries, into the major index and provides 
a separate index for all the named modules 
within the program. 

In its current format, the index presents 
each unique variable name once. A single 
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Current index 

result : 10, 11, 12, 14, 18, 33, 35, 36, 
38, 40, 42,4£,47, 50,51 

Enhanced index 

result: 

in get_next(): IQ, 11, 12, 14, 18 
it mult(): 33, 35, 36, 38, 40, 42 
it produce_value(): 45, 47, 50, 51 


Figure 14. Current Web index vs. en¬ 
hanced index. 


variable name used in different locations 
for different purposes shows up as only one 
entry in the index. This entry is listed as 
being defined in a number of different 
modules. (The convention of underlining a 
module number indicates that the identi¬ 
fier is defined in that module.) 

Multiple instances of the same variable 
name must be discovered manually. By 
enhancing the current index format, it is 
possible to capture the individual variables 
within the index, listing the common 
variable name and noting the enclosing 
procedure or function as shown in Figure 
14. This information is obtained by exam¬ 
ining the source code generated within the 
literate program. 

Additionally, the ability to provide Weave 
with runtime options regarding the format 
of the presented index would improve the 
interface for the program reader. Allowing 
an individual to select any or all of the 
program identifiers and author-generated 
entries and place them into separate ap¬ 
pendixes would also benefit the reader. For 
example, the person concerned with port¬ 
ing the program might want to place all 
system dependencies and user-defined in¬ 
dex entries in a separate index. The main¬ 
tenance programmer might want to sepa¬ 
rate program variables, program functions, 
and procedures, as well as constant decla¬ 
rations. 

Restrictions imposed on the current 
implementation. In addition to the recom¬ 
mendations we made regarding new fea¬ 
tures for literate programming, we believe 
the use of a number of existing features 
should be curtailed; specifically, restric¬ 
tions on the structure of literate programs 
and the size of the literate command set. 


Restrictions on the structure of literate 
programs. The first set of restrictions re¬ 
garding literate programming limits the 
physical structure of an individual module. 
Each module within the program should 
function as a logical single entity, as a 
normal block-structured language would 
demand. Each module containing a “be¬ 
gin” for some segment of code must con¬ 
tain a corresponding “end” statement. Nat¬ 
urally, the contained code may use 
submodules to abstract out the details of 
the processing. However, each function, 
procedure, or block opened within a given 
module should always be closed within the 
same module. 

The restriction regarding begin-end 
constructs not only helps in defining mod¬ 
ule functionality but also assists the reader 
in tracking variable definitions and scope. 
Variables declared in a module that spans 
the next several modules can find their 
declaration hidden from the maintenance 
programmer. The scope of individual vari¬ 
ables is more apparent in single-module 
functions and procedures. 

Related to this issue is the demand that 
all functions and procedures within the 
program be contained in separate modules. 
The inclusion of multiple functions within 
a single module can obscure or convolute 
the purpose of the individual functions. By 
separating each into its own module, the 
interface to any single function is more 
apparent. 

Reduction of the literate command set. 
The commands that allow the programmer 
to fine-tune the typesetting of a literate 
program should be sharply reduced. For 
example, CWeb currently defines three 
different commands (@ A , @., and @:) that 
allow the programmer to enter a string in 
the program index. These three vary only 
in how the string is typeset. Instead, use a 
single command and, if necessary, add the 
typesetting instructions to the string itself. 

Literate typesetting commands permit 
the programmer to override the standard 
formatting algorithms used within the 
Weave program. The programmer is thus 
capable of producing code that conforms 
to individual stylistic considerations and 
not a universal standard. 

In conjunction with this elimination of 
Web typesetting commands, a template- 
based documentation generation routine 
must be provided. Programmers or organi¬ 
zations should be able to provide a tem¬ 
plate for all program documents generated 
in the literate environment. Any code gen¬ 
erated in this environment would conform 


to the standards set in this template. Com¬ 
panywide standards for documentation style 
could be implemented with little overhead 
to individual programmers. 

If the Web programmer has the use of a 
literate-programming environment, as de¬ 
scribed in Brown and Childs, 11 program¬ 
ming in Web can be done without explicit¬ 
ly using any Web commands. However, 
many programmers do not have access to 
such a tool, and the Web command set must 
be used. This set of commands should be as 
small as possible. 

T he literate paradigm offers a plat¬ 
form for code generation that pro¬ 
motes readability and understand- 
ability. As it exists today, this platform is 
ill-suited for adoption by most software 
developers. The lack of a proper interface 
into the software development life cycle, 
the lack of an environment that minimizes 
the overhead associated with the literate 
paradigm, and the awkwardness of current 
literate languages discourage the adoption 
of literate techniques. Furthermore, to of¬ 
fer a practical, usable methodology for 
software development, the literate para¬ 
digm must encompass the entire life cycle, 
not just the implementation phase. 

However, these obstacles are not insur¬ 
mountable. As we outlined, techniques exist 
to eliminate or minimize a number of po¬ 
tential problems with today’s literate¬ 
programming languages. As more tools 
become available for literate programming, 
the paradigm will become appealing to a 
wider audience. Perhaps the second gener¬ 
ation of literate-programming languages 
will gain the acceptance that those in the 
first generation sorely missed. ■ 
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A Classification of 
Transaction Processing 
Systems 


Avraham Leff and Calton Pu 
Columbia University 


D atabase performance depends on 
both external and internal func¬ 
tionality. External functionality 
encompasses such issues as data models 
and query languages. Internal functional¬ 
ity involves file structure, indexing, and 
query optimization. Users are explicitly 
confronted with aspects of external func¬ 
tionality, while internal functionality is 
necessary for performance. A third area, 
often taken for granted, is crucial in a 
user’s interaction with the database. This 
area involves the transaction constraints 
imposed to achieve recovery atomicity and 
concurrency atomicity.' 

In a database with recovery atomicity, 
when a user initiates a transaction, the 
transaction either executes in its entirety or 
has no effect whatsoever on the database. 
Thus, even if underlying hardware or 
software fails, application programs do not 
corrupt the database with incorrect results. 
The concurrency property, on the other 
hand, assures users that concurrent execu¬ 
tion of another transaction does not affect 
their own applications. To achieve con¬ 
currency atomicity, a transaction process¬ 
ing system controls execution of transac¬ 
tions so that their interleaved executions 
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We identify specific 
problems in 
implementing 
transaction properties 
and abstract them into 
a set of common system 
dimensions to construct 
a classification of 
transaction processing 
systems. 


are equivalent (in their effect) to some 
serial execution. Such transactions are said 
to be serializable. Recovery atomicity is a 
general recovery technique that is prov- 
ably correct and provides fault tolerance. 

0018-9162/91/0600-0063$01.00 © 1991 IEEE 


Similarly, concurrency atomicity is a prov- 
ably correct general technique for increas¬ 
ing concurrency without introducing in¬ 
consistency into the database or into users’ 
results. 

Both atomicity properties are intuitively 
appealing because they allow users to think 
of a complex database application program 
as an atomic, fail-safe modification of the 
database. Although many people simulta¬ 
neously use the database and it is subject to 
many forms of real-life failure, transaction 
processing systems let users ignore these 
complexities. In other words, transaction 
processing systems let each user think of 
himself or herself as the sole user of an 
idealized, failure-free database system. 

Transaction constraints are easily stat¬ 
ed, but implementing them in database 
systems is difficult. For a database system 
to be a transaction processing system as 
well, it must have additional mechanisms. 
The nature and complexity of these mech¬ 
anisms vary from system to system. When 
the underlying database is simple (for ex¬ 
ample, it runs on a PC), the problems are 
relatively few. But if the database system is 
built on a network of machines, the prob¬ 
lems are much greater. The difficulties are 
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compounded when machines are heteroge¬ 
neous with respect to their database man¬ 
agement system software or simply their 
hardware. 

In this article we discuss the problems in 
building a transaction processing system 
and show that the difficulties are a function 
of specific attributes of the underlying da¬ 
tabase system. We classify the attributes 
along five dimensions and analyze the spe¬ 
cific problems posed by various combina¬ 
tions of system characteristics. In the next 
section, we present a model of a transac¬ 
tion processing system and introduce the 
dimensions important in classifying trans¬ 


action processing systems. Then we ana¬ 
lyze the effect of moving along the different 
dimensions, emphasizing the independence 
of these dimensions. Finally, we describe 
the evolution of transaction processing 
systems in terms of our framework. 

Model and terminology 

Figure 1 shows a hardware model of a 
transaction processing system. A network 
such as a local area network or a wide area 
network connects a number of machines. If 
the system has a single machine, it does 


not, of course, need access to a network. 
Each machine contains a CPU and main 
memory, and can access nonvolatile data 
on disk. The software model of a transac¬ 
tion processing system in Figure 2 shows 
the features that distinguish a transaction 
processing system from a database system. 
Users access the database with the usual 
query and update processing, but the in¬ 
teraction is controlled by two modules that 
reside on top of the database: a concurrency 
control module and a recovery manager 
module. 

To classify transaction processing sys¬ 
tems, we use five dimensions: 

• M is a set of machines (each possessing 
memory and a CPU) on which the processes 
run. Information can be transmitted between 
machines via a communication network, as 
shown in Figure 1. 

• P is a set of processes that run on the 
machines. Each process is an abstract en¬ 
tity of computation (for example, a thread 
of control). When a user inputs a database 
request at the terminal, a process is invoked 
to satisfy the request. 

• H is the degree of heterogeneity among 
the set of machines and associated system 
software. The diagram in Figure 1 does not 
constrain the machines to be identical in 
any way. 

• D is a set of logical data. Each logical 
data schema is coupled with a mapping 
mechanism, so that when a user reads a 
logical datum, the system always returns a 
unique and consistent value. The physical 
data reside in main memory and on disk; 
the logical schemas enable the user to 
correctly interpret and conveniently access 
this data. 

• S is a set of sites. Sites support one or 
more logical schemas and consist of the 
machines in the database system. A machine 
can access a schema only if the machine 
belongs to a site that supports the schema. 

We represent a transaction processing 
system as a quintuple expressed by P, M, 
H, D, and S. Each system is designed so 
that a program running in the system 
manifests the transaction properties of re¬ 
covery and concurrency atomicity. In other 
words, the concurrency control and recovery 
manager modules shown in Figure 2 sup¬ 
ply users with a consistent and useful way 
to interact with the database system, no 
matter how complex the underlying system 
components are. These two modules enable 
transaction processing systems to ensure 
that the interaction appears atomic with 
respect to other processes in P (concurrency 
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atomicity) and failures in machines in M 
(recovery atomicity). 

We consider the issue of data models to 
be orthogonal to our model of transaction 
processing systems. Systems can describe 
data through record-based models such as 
the relational, network, and hierarchical 
models, or through object-based logical 
models such as the entity-relationship and 
semantic network data models. We merely 
assume that some formalism exists to de¬ 
scribe the data of processes. 

The complexity of implementing trans¬ 
action processing systems depends on the 
complexity of the underlying database 
system. The dimensions in the (P, M, H, D, 
S ) quintuple capture many system aspects 
that affect the implementation, and allow 
us to simplify the complexity by analyzing 
each dimension in isolation. The key issue 
in our tuple model is the cardinality of the 
sets P, M, H, D, and S. The most significant 
problems arise as the cardinality of these 
sets changes from 1 to n. To denote the case 
when the system has only one machine, we 
write M,. When the system consists of many 
machines, we write M„. In a later section 
we vary the cardinality of each of the five 
components and examine the effect on the 
resulting transaction processing system. 
Some system dimensions are orthogonal to 
others, and solutions for the problems in 
such dimensions remain valid even when 
we change other dimensions. We denote 
such a case by a subscript x, which indi¬ 
cates a “don’t care” for the value of the 
dimension. It is actually more appropriate 
to view the heterogeneity and data com¬ 
ponents as more than simply binary valued; 
therefore, we present a multivalued metric. 

In changes from one to many or from 
low degree to high degree, for each di¬ 
mension the issue is as follows: 

• P: concurrency 

• M\ coordination (protocols and algo¬ 
rithms) 

• H: machine and software heter¬ 
ogeneity 

• D: data homogeneity 

• S: management 

Table 1 lists the systems we discuss in 
this article in terms of the five transaction 
processing system dimensions. The entries 
in the table denote the cardinality of the 
system: 1 means there is one entity or low 
complexity, n means multiple entities or 
higher complexity, and k is a value be¬ 
tween 1 and n. We elaborate on these ideas 
in the section on systems evolution. 


Table 1. Transaction processing system quintuples. 


System 

Process 

Machine 

Heterogeneity 

Data Site 

System/U 

n 

1 

1 

1 1 

System R 

n 

1 

1 

k 1 

Ingres 

n 

1 

1 

k 1 

SDD-1 

n 

n 

1 

1 1 

Porel 

n 

n 

1 

1 1 

Distributed Ingres 

n 

n 

1 

k 1 

R* 

n 

n 

1 

k n 

Sirius-Delta 

n 

n 

n 

k 1 

Preci* 

n 

n 

n 

k 1 

NDMS 

n 

n 

n 

k 1 

MRDSM 

n 

n 

n 

n n 


Taxonomy 

instantiations 

With the many possible variations in the 
five parameters, it is helpful to examine 
each system type separately. 

Base systems ( P„ M„ H u D t , SJ. In a 
base system, only a single process can run 
at a time on a single machine. One data 
schema is supported by a single site. Because 
of the simplicity of each component, this 
case poses the fewest difficulties in im¬ 
plementing transaction constraints. 

Concurrency atomicity is available 
trivially. Because of the real-life failure 
properties of the machine, recovery atom¬ 
icity must be supported by such mechanisms 
as logging or shadow paging. 

The system’s transformation of logical 
data to physical data requires only a fairly 
simple mapping because the data reside on 
the machine running the process and the 
site supports only one data schema. 
Mechanisms such as a database dictionary 
and a file manager can locate, access, and 
present the data in an appropriate format. 
However, the construction of a single logical 
view of the world representing the view¬ 
points of a number of users is a nontrivial 
task. 

This base system may seem so simple 
that it does not exist in the real world. But 
many database products for PCs resemble 
this system to the extent that users take 
concurrency atomicity for granted. Protec¬ 
tion against system failures is not provided 
with standard PC products because the 
overhead for recovery atomicity is pro¬ 
hibitive. However, the base system is in¬ 
teresting because more complicated sys¬ 
tems are attempts to map the underlying 


machines, processes, and other components 
into this simple and appealing interface. 
Despite the multiple processes, machines, 
and data, the system attempts to transpar¬ 
ently offer users the illusion that they are 
dealing with the base system. 

U nimachine systems (P„, M, ,H„ D „ S ,). 
In a system that can run more than one 
process concurrently but otherwise has the 
same parameters as the base system, the 
database offers only one view of the world. 
The critical distinguishing feature of such 
a system (in terms of implementation) is 
the single machine, so we call it a unima¬ 
chine system. 

Concurrent process execution does not 
affect implementation of recovery atom¬ 
icity, which is supported as in the base 
system. Similarly, supplying data to many 
processes is no more difficult than supplying 
data to a single process. 

Supporting concurrency atomicity is a 
problem because one program can change 
a datum’s value in the middle of another 
program’s execution. Serializability must 
be implemented so that the set of concur¬ 
rent processes is equivalent to a schedule 
of serially running processes. Various 
concurrency control schemes can ensure 
serializability. An example is a locking 
protocol; the most common is two-phase 
locking. Such protocols ensure that pro¬ 
cesses do not acquire or release locks on 
data in just any way. Instead, systems ad¬ 
here to specific, provably correct protocols. 
Other mechanisms are time-stamp ordering, 
multiversions, and validation techniques. 

Multimachine systems ( P X ,M„,H,,D„ 
S,). In a multimachine system, processes 
may require more than one machine to 
execute. The tuple represents a database 


June 1991 


65 







with distributed processors and physical 
data. Here, we are not concerned with 
distributed computation, in which more 
than one processor contributes cycles for 
the process’s execution. Even if a process 
runs on only one machine, it may access 
data residing on a different machine. Dis¬ 
tributed data systems allow users to take 
advantage of other users’ data, even if the 
data exist on other machines. 

There is a continuum between “one” and 
“many” machines, and the boundary for 
this dimension can be fuzzy. For example, 
a tightly coupled multiprocessor is a single 
machine; a cluster sharing data is really 
many machines. Similarly, a system based 
on shared memory functions as a transac¬ 
tion processing system implemented in a 
multimachine environment. The details of 
systems architecture are important. Nev¬ 
ertheless, the extremes of the “single ver¬ 
sus many” machine continuum are clearly 
marked, so we do not deal with the many 
variations of the machine dimension. 

Concurrency atomicity is affected by 
the possibility of various failure modes. 
Unlike unimachine systems, which cannot 
operate when a software or hardware 
component fails, multimachine systems 
have mechanisms to permit parts of the 
transaction processing system to continue 
functioning despite failure of another part, 
along with mechanisms to facilitate the 
eventual recovery of the overall system. 
System memory management affects data 
replication. With a unimachine it does not 
pay to replicate data, because performance 
improvements are usually not great, and if 
the system fails, all data are equally inac¬ 
cessible. (Highly available transaction 
processing systems such as Tandem, which 
do replicate data and are managed as a 
unimachine, are in fact multimachines be¬ 
cause all system resources, including 
hardware, are replicated.) 

In a multimachine transaction process¬ 
ing system, supplying data for transactions 
can be complex. Data physically reside on 
any number of machines, although they are 
mapped into a single logical schema sup¬ 
ported by the single site. These data relate 
to one another along two dimensions: 

• Fragmentation denotes the extent to 
which the data used by the set of processes 
running on a machine physically exist on 
that machine. At one extreme of fragmen¬ 
tation, no data must be retrieved from an¬ 
other machine. At the other extreme, the 
data are horizontally or vertically frag¬ 
mented over different machines and must 
be reconstructed for use by the executing 


In a multimachine 
transaction processing 
system, supplying data 
for transactions can 
be complex. 


machine’s process. When data are hori¬ 
zontally fragmented, certain objects residing 
on many machines are identified as logically 
belonging to the same set of objects (for 
example, a table or other “entity”). When 
data are vertically fragmented, certain ob¬ 
jects are identified as modeling the same 
“larger” object. The objects differ from 
one another in the amount of information 
— for example, how many attributes — 
they each contain about the larger object. 

• Replication denotes the degree to which 
data used by processes running on a machine 
exist on other machines. At one extreme of 
replication, the data exist solely on the 
executing machine. At the other extreme, 
data are replicated on all machines. If only 
one logical schema is available to processes, 
only the relationships of disjoint union and 
equivalence exist between the logical data 
residing on the system’s machines. Either 
the data are disjoint concepts or they 
identically model the same concept. 

Because redundancy in distributed da¬ 
tabases increases performance, reliability, 
and availability, the extremes of both no 
replication and no fragmentation define a 
degenerate point in the space of distributed 
data. The point implies that all data reside 
on one machine and the other machines 
contain no other database data whatsoever. 
At any other point in this space, some 
coordination between machines is required 
to ensure that the underlying data remain 
consistently defined. As before, a single 
logical schema formalizes this coordination, 
but the coupled data mapping mechanism 
is now considerably more complex. 
Moreover, before implementing the 
mechanisms for mapping logical to phys¬ 
ical data, designers must decide where to 
locate and how to fragment the data, and 
what level of efficiency to achieve. 

A catalog table frees the user from 
specifying a particular replica: The system 
uses the table to track down all replicas of 


the data item. The system can create a set of 
aliases (alternative names) and translate 
the user’s simple name into a location- 
specific name. Similarly, the process ac¬ 
cesses data in unfragmented form. Then 
the system must optimize the request so 
that only necessary data are reconstructed. 

We turn now from how multiple machines 
affect the data used by transactions to how 
transaction properties are implemented in 
a multimachine environment. A global 
process satisfies transaction constraints by 
updating data that reside on machines other 
than the machine running the process. A 
local process updates only data residing on 
the machine that executes the process. If 
each machine in the system already has 
transaction processing mechanisms in place, 
nothing new has to be done to run processes 
if they remain local processes. However, 
the system must be able to run global pro¬ 
cesses that maintain transaction constraints. 
Moreover, global processes must not in¬ 
terfere with the transaction behavior of 
local processes. We term the additional 
mechanism needed to run global processes 
on an (A/„) system the global mechanism. 

Multimachine system coordination. To 
guarantee the all-or-none recovery atomicity 
characteristic, a system needs a commit 
protocol requiring information about more 
than one machine. A process whose exe¬ 
cution was initiated at one machine must 
either commit or abort at all machines 
participating in its execution. Such coor¬ 
dination among the machines satisfies the 
atomicity constraint. It is usually achieved 
with variations of the two-phase commit¬ 
ment protocol, whose critical feature is a 
transaction coordinator that sends messages 
to and receives messages from all partici¬ 
pating machines. If all participants agree, 
the protocol makes an atomic decision re¬ 
garding the commitment 2 and all partici¬ 
pants must adhere to it. Examples of such 
protocols include the “presumed-abort” and 
the “presumed-commit” protocols (devel¬ 
oped for IBM’s R* system), which reduce 
the number of message exchanges and log 
operations required by the basic agreement 
protocol. 

A base system is concerned with only a 
single process running at a time. Concur¬ 
rency atomicity is therefore available 
trivially. In a multimachine system — as in 
a unimachine system, where the process 
parameter changes from 1 to n — supply¬ 
ing recovery atomicity does not become 
more difficult (once the commit protocol is 
in place). What changes in a multimachine 
system is the task of supplying concurrency 
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atomicity. Because one process can now 
interfere with the data needed by another 
process, the transaction processing system 
must ensure serializable execution. Solu¬ 
tions to this problem cannot be trivially 
applied as with unimachine systems. 

To serialize a set of processes in a dis¬ 
tributed environment, the system must 
determine a serializable schedule of pro¬ 
cesses spanning multiple processors. The 
problem, in other words, is coordinating 
multimachine activity. Many distributed 
concurrency algorithms have been sug¬ 
gested. Bernstein and Goodman 3 point out 
that most are modifications to either the 
locking or time-stamp mechanisms devel¬ 
oped for the centralized case. 

Distributed concurrency algorithms us¬ 
ing locking protocols differ in how they 
implement the lock manager. Where data 
is not replicated, some systems maintain a 
single lock manager and some maintain a 
lock manager at each machine (multiple 
coordinators). The former approach is a 
trivial extension of the single-processor 
case, and the coordinating processor is a 
bottleneck that leaves the system vulnera¬ 
ble. If a system can generate globally unique 
time stamps, it can use unimachine time- 
stamp mechanisms extended for nonrepli- 
cated data. The transaction processing 
system then uses the unique time stamps to 
determine the serial order. Both the lock¬ 
ing and the time-stamp algorithms apply a 
centralized approach to the distributed 
setting and do not work in systems that 
replicate data. 

Multimachine systems with replicated 
data. With a multiplicity of machines, the 
provision of reading access for a process is 
difficult. Moreover, maintaining database 
consistency requires that the system change 
the value of data in an all-or-none manner. 
When data are fully replicated at each 
machine, reading data is theoretically no 
more difficult than in a centralized system. 
But while writing data, the system must 
maintain consistency between machines. 
Even more information must be shared and 
coordinated if the fragmentation relation¬ 
ship holds between machines. When data 
are replicated, the system must decide how 
to make a global decision (lock a data item) 
and ensure that individual processors are 
aware of the decision and do not let another 
process access their copy. 

In other words, the problem is the same 
as with supplying concurrency atomicity: 
How can a global activity be coordinated to 
avoid inconsistent results? Unimachine 
system locking protocols can be extended 
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to multimachine systems. These include 
the “primary copy” and “majority” proto¬ 
cols. Time-stamp mechanisms can be ex¬ 
tended to handle replicated data via “mul¬ 
tiversions,” where each version is the state 
of some data after an update. With this 
approach, the system determines the ver¬ 
sion appropriate for a given transaction 
according to the time associated with the 
version. 

Coordination is difficult enough even 
when the system operates without failures. 
Independent failures in a system affect 
consistency among a datum’s copies, 
making management of replicated data 
still more difficult. For example, when a 
single site crashes, does the unavailability 
of its copy mean that other sites cannot 
access their copies? Naive approaches to 
replicated data management can lead to an 
ironic result: Replicated data, whose pur¬ 
pose is to increase availability, in practice 
reduce availability because a single failure 
in a multicomponent system leads to 
complete unavailability. Communication 
failures introduce an even more difficult 
problem when they partition the system. 
Transactions executing in different com¬ 
ponents of the system may have conflict¬ 
ing updates to copies of the same item, and 
a communication failure prevents imme¬ 
diate synchronization of the updates. 

Various solutions enable management 
of replicated data even in the real-world 
presence of failures. 2 Available-copies 
algorithms deal with site failures by ap¬ 
plying updates to all available sites and 
using a validation protocol to ensure that 
consistency is maintained. Algorithms such 
as quorum consensus and virtual partitions 
deal with communication failure by pro¬ 
hibiting some sites from applying updates 
(while permitting others) in a controlled 
fashion. These algorithms work because 
the partitions have enough information to 
determine whether they can apply the up¬ 
date. 


Heterogeneous systems (P X ,M„, H„D„ 
Si). In discussing the machine parameter, 
we assumed a homogeneous environment 
in which the machines share identical 
hardware, operating systems, and database 
management systems. Even with system 
homogeneity, changing the cardinality of 
M from 1 to n introduces considerable 
difficulty in building a transaction pro¬ 
cessing system. The underlying problem is 
one of coordination: The system must co¬ 
ordinate the set of machines so that they 
behave as a single machine obeying the 
constraints on processes. In this section, 
we examine the effect of heterogeneous 
components on a transaction processing 
system. 

The process and machine dimensions do 
not specify anything about homogeneity 
among the machines making up the system. 
The machines can differ in their hardware 
(computer architecture), operating systems, 
and database systems. When machines 
differ, information to coordinate the ma¬ 
chines must be mapped from one form to 
another. 

Each architecture level allows a direct 
and an indirect approach to the mapping 
problem. Each approach has costs and 
benefits. The direct method maps from the 
source representation to the destination 
representation. For K sources and N desti¬ 
nations, this requires (K * N) translation 
routines. The indirect method proceeds in 
two steps. First, it translates every source 
representation into some standard repre¬ 
sentation. Then it translates the standard 
representation into a destination represen¬ 
tation. For AT sources and ^destinations, this 
gives (K + N) translation routines. At the 
database level itself, in the multimachine 
(but single-process) transaction processing 
system the commitment protocols of each 
machine must be mapped; in a multiprocess 
system (P„, M „, H t , D„ S,), the serializ- 
ability mechanisms of the machines must 
also be mapped. 

Much of the heterogeneity that a multi¬ 
machine environment presents is in fact 
handled (at each level of the hierarchy) by 
an indirect mapping of the set of lower 
level instances to an abstraction of those 
instances. Thus, a function of the operating 
system is to present the user with a virtual 
machine that is easier to program than the 
underlying hardware. Appropriate system 
software can present heterogeneous hard¬ 
ware to the user as a homogeneous virtual 
machine. Because commercial database 
products are built on top of existing oper¬ 
ating systems, researchers often ignore the 
problem of heterogeneous hardware because 
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they assume that operating systems have 
solved the problem. 

Different operating systems offer differ¬ 
ent services in different ways. But data¬ 
base users can ignore this heterogeneity 
because database management systems are 
another layer of software designed to present 
users with the same type of database, re¬ 
gardless of the underlying operating system. 
Generally, a commercial database product 
can run on different types of PCs as well as 
on different networks. The database man¬ 
agement system is a layer of software that 
maps operating systems into various data¬ 
base functions. 

Such mappings do not cause problems, 
so we do not discuss further the issue of 
heterogeneity in the nontransaction aspects 
of the system. On the other hand, the 
mapping needed to implement the critical 
transaction constraints is essentially an open 
problem. Heterogeneity complicates the 
top-level mapping of the local database 
management system into the global DBMS 
that supports the global mechanism. A 
cardinality of n in the set M makes imple¬ 
menting these constraints difficult because 
any given machine must be aware of some 
other machine to run a process. Heteroge¬ 
neity introduces further difficulty because 
machines need more information — the 
mapping mechanism — for the system to 
operate. If the transaction processing sys¬ 
tem is constructed in top-down fashion, 
machines do not need different protocols 
or algorithms. The difficulty arises when 
the system is constructed in bottom-up 
fashion with different concurrency or re¬ 
covery atomicity implementations at the 
individual machines. Then the heterogene¬ 
ity dimension changes from 1 to n. 

Approaches to machine heterogeneity. 
At first glance there seems to be only one 
way to deal with H n : However difficult the 
task, construct either a direct or an indirect 
mapping so that machines’ mechanisms 
can map into one another. Database im- 
plementers have often hesitated to do this 
because the benefit of getting global pro¬ 
cesses with transaction properties is out¬ 
weighed by the cost of interfering with 
local processes. 

Gligor and Popescu-Zeletin 4 identify an 
inherent trade-off between redesign effort 
and functionality in implementing con¬ 
currency and recovery atomicity within 
heterogeneous machines. On the one hand, 
if the global mechanism leaves local 
mechanisms unmodified, global concur¬ 
rency and recovery atomicity have limited 
functionality. On the other hand, modify - 
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ing local mechanisms to enforce transac¬ 
tion constraints on global processes re¬ 
quires considerable redesign effort because 
DBMSs typically do not provide clean in¬ 
terfaces. Database implementers hesitate 
to expend this effort because the machines 
can function “as is” to the extent that local 
processes can run without any additional 
effort. Moreover, if machine linkage is not 
permanent and machines can revert to be¬ 
ing unimachine systems of the form (P„, M„, 
H^D,, S,), interference with local mecha¬ 
nisms would make leaving the network 
more difficult. 

The designers of Computer Corp. of 
America’s Multibase explicitly opted for 
no redesign of local sites. As a consequence, 
Multibase provides no global update or 
transaction capability whatsoever. At the 
other end of the continuum, INRIA ’ s Sirius- 
Delta provides reliability and atomicity, 
but limits heterogeneity even more because 
the participating DBMSs must all be Co- 
dasyl-type systems. Sirius-Delta imple¬ 
ments atomicity with two-phase commit 
and two-phase locking, and a write-all 
method handles updates. 

Some researchers have escaped the re- 
design-versus-functionality trade-off by 
proposing that local concurrency and re¬ 
covery atomicity mechanisms be simply 
concatenated to provide global serializ- 
ability and atomicity mechanisms. Gligor 
and Popescu-Zeletin 4 list five conditions 
that suffice for constructing a global seri- 
alizability mechanism from a concatenation 
of local serializability mechanisms without 
loss of functionality. However, they do not 
offer algorithms for the concatenation. 

Using similar assumptions, Pu shows 
how both recovery and concurrency ato¬ 
micity transactions can be implemented in 
an (M„, H n ) system through hierarchical 
composition across database boundaries. 5 
If local sites understand an agreement 
protocol such as two-phase commit (nec¬ 
essary for recovery atomicity) and each 
site can provide an explicit serial ordering 


of its local processes (necessary for serial¬ 
izability), then a system can effect consis¬ 
tent and reliable global updates even in an 
H n environment. A sufficient but not nec¬ 
essary condition for global serializability 
(given local serializability) is that the glo¬ 
bal component certify compatibility of all 
local serial orders in a global serial order. 
Moreover, local sites can easily provide 
certification themselves in a representa¬ 
tion (called an order-element) produced 
by two-phase locking, time stamps, and 
optimistic serializability methods. 

Pu’s assumptions differ from those of 
Gligor and Popescu-Zeletin in that hierar¬ 
chically composed databases, or superda¬ 
tabases, certify serializability after process 
execution; this is an optimistic approach. 
Gligor and Popescu-Zeletin specify that 
local serializability must preserve the rel¬ 
ative order of execution determined by the 
global component; this is a pessimistic 
approach. Also, Gligor and Popescu-Zele¬ 
tin specify a condition concerned with 
global deadlock detection. Pu does not 
solve this problem, but suggests that the 
time-out mechanism used so much in dis¬ 
tributed systems can also be used to break 
deadlocks. 

Machine heterogeneity and autonomy. 
Implementers of transaction systems have 
increasingly attempted to incorporate het¬ 
erogeneous components. Our key assump¬ 
tion in the previous discussion of tech¬ 
niques that provide global recovery and 
concurrency atomicity is that the system 
components cooperate in providing global 
transaction properties. Some researchers 
now question this assumption and say that 
heterogeneous components do not coop¬ 
erate — at least, they do not wish to co¬ 
operate if global constraints interfere with 
local system performance. For example, in 
the commit phase of the two-phase com¬ 
mit protocol, a local component may try to 
commit a transaction, even though the 
global coordinator aborts the transaction. 6 
In many other areas, participation in a 
global transaction scheme infringes on a 
local transaction system’s capabilities. 
Because of this concern, researchers are 
devoting much effort to providing global 
transaction capabilities, while allowing 
local systems to maintain individual au¬ 
tonomy. 78 A key issue here is the defini¬ 
tion of autonomy. One person may consider 
local systems with local two-phase commit 
components reasonably autonomous. An¬ 
other person may consider this arrange¬ 
ment a violation of autonomy. 

In our analysis we consider the dimen- 


68 


COMPUTER 










sion of autonomy to be independent of 
heterogeneity or other intrasystem barri¬ 
ers. In other words, the issue of autonomy 
arises only when the thing preventing free 
access to database resources is some form 
of control. Heterogeneity may be a motiva¬ 
tion for autonomy if we assume that orga¬ 
nizations do not want and therefore do not 
authorize significant database system 
modification. Then, in naive heterogeneous 
database systems, heterogeneity is often 
resolved through modification of or addi¬ 
tion to component systems. However, an 
equally valid view is that autonomy is a 
motivation for system heterogeneity: To 
keep other people from taking over their 
data, a suborganization may encourage 
various degrees of heterogeneity so that 
their system cannot be integrated with oth¬ 
ers. Therefore, we later discuss autonomy 
in the context of the site parameter. The 
issue of how flexible global system design¬ 
ers can be about local system components 
when providing a global transaction capa¬ 
bility remains open. 

Machine heterogeneity metric. We have 
discussed a continuum of system heteroge¬ 
neity in terms of three points: (M,, H t ), (M,„ 
H { ), and (M„, H„). These denote, respec¬ 
tively, processes running on one machine, 
on n identical machines, and on n distinct 
machines. The identical-distinct dichoto¬ 
my simply indicates whether machines run 
the same centralized DBMS. Earlier, 
however, we noted a layering of heteroge¬ 
neity on top of real machines that maps 
operating systems onto the hardware, 
DBMSs onto the operating system, and a 
global database manager onto the compo¬ 
nent DBMSs. At each of these layers the 
underlying components can be homoge¬ 
neous or heterogeneous. An accurate as¬ 
sessment of a transaction processing sys¬ 
tem captures the various heterogeneity 
components with a heterogeneity metric 
that describes the set of machines in M . The 
cardinalities of each layer’s components 
become elements in a heterogeneity vec¬ 
tor. We then normalize the vector to yield 
a single number. More research is needed 
to develop a norm that can adequately 
convey the work needed to get the transac¬ 
tion processing system to function despite 
the heterogeneous components. 

Multischema systems ( P x , M n , H„ D„ 
S,). In this section we examine transaction 
processing systems that support more than 
one data schema — we increase the cardi¬ 
nality of the data parameter from 1 to n. Such 
multischema systems fall into two catego- 
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ries. On one hand, a system may have only 
one logical view of the world but more than 
one coupled mechanism to map logical 
data to actual data. In other words, the 
system supports inconsistent values. On 
the other hand, a system may support 
schemas that are actually different at the 
logical level. When we discuss the data 
parameter, differences do not have equal 
importance. The difference between logi¬ 
cal schemas lies on a continuum, bounded 
by syntactic heterogeneity (the least dif¬ 
ference) at one extreme, and semantic 
heterogeneity (the greatest difference) on 
the other. We can quantify the difference 
by the degree of effort required to resolve 
the conflicts. 

The salient point of syntactic heteroge¬ 
neity is that everyone readily understands 
that a single underlying concept is involved: 
The problem is merely that this concept is 
not expressed in a common language. In a 
transaction processing system this situation 
arises trivially either when the interfaces to 
the logical data differ (the data model 
languages) or, less trivially, when the data 
on the different machines are logically 
organized in more than one data model (for 
example, network, relational, hierarchical, 
or entity-relationship models). Naming 
conflicts are a second source of syntactic 
problems. These include synonyms (dif¬ 
ferent components use different names for 
the same data entity) and homonyms (dif¬ 
ferent components use the same name for 
different data entities). 

Even when data on the machines are 
organized with the same data model and 
schema interfaces are identical, there can 
be subtle and major disagreements between 
the schemas about the nature of the world 
they model. Batini, Lenzerini, and Na- 
vathe 9 identified two types of semantic 
diversity: intraschema diversity and in¬ 
terschema diversity. Intraschema diversity 
refers to differences among the component 
schemas with respect to common concepts. 
For example, a dependency conflict arises 


when one schema models the manager- 
employee relation as 1 :n and another 
schema models the relation as m:n because 
in an organization with the latter schema, 
an employee may work for two managers. 
Such conflicts arise from different choices 
in selecting modeling constructs or in fix¬ 
ing integrity constraints. Interschema di¬ 
versity refers to relationships among distinct 
concepts in the component schemas. For 
example, if one schema models managers 
and another models people, closer inspec¬ 
tion of the schemas may show that the 
“manager” concept is a subset of the 
“people” concept. As a result, the schema 
may now need to include gender informa¬ 
tion, which was not part of the original 
manager schema, if the manger-person 
subset relationship is to be useful in other 
contexts. Navathe and Gadgil identify other 
relationships such as categorization and 
partitioning. 10 

Intraschema differences are more syn¬ 
tactic than interschema differences because 
we cannot discover interschema differences 
simply by comparing the way concepts 
common to the schemas are modeled. We 
perceive such differences only after con¬ 
sidering all the underlying schema as¬ 
sumptions, and these are rarely explicit. 

Some types of data model heterogeneity 
lie on the border between syntactic and 
semantic problems. They are not purely 
syntactic because the differences involve a 
different conception of external reality, 
but they are not really semantic because 
people would readily agree that the systems 
are modeling the same phenomena. For 
example, a system may incorporate a data 
representation conflict: Are pay raises in¬ 
teger or real-valued quantities? In a sense, 
when the mapping mechanisms differ so 
that the site supports schemas with incon¬ 
sistent values, the difference between the 
schemas also lies in the middle of the 
syntactic-semantic data heterogeneity 
continuum. 

By supporting data heterogeneity, the 
(P„ M„, H x , D„, 5,) tuple supports a richer 
and more realistic model of the world. 
People do have inconsistent views of the 
world, and forcing everyone to conform to 
a single schema is very limiting. In addition, 
a multiplicity of views enables the system 
to incorporate greater security. Often we 
do not want all users to have complete 
knowledge of even the structure of the 
system’s data. If only one schema is 
available, it is harder to isolate such 
knowledge. When the site can support more 
than a single view, we can make informa¬ 
tion available to users on a need-to-know 
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basis. A given process knows only about a 
given schema, whereas other processes have 
access to different schemas. 

Supporting more than one data schema 
requires more effort than the mechanisms 
we discussed in the single-schema qua¬ 
druples. However, the effect is essentially 
linear because we simply multiply by the 
number of schemas the work of maintain¬ 
ing the data mapping, coordinating between 
the site manager and users, and so on. In the 
transition from an (M,, D n ) system to an 
(Af„, D„) system (where the actual data re¬ 
side on a number of machines), the only 
new problem is maintaining consistency of 
schemas across a network of machines. 
However, it is difficult to automatically 
propagate updated results to the underlying 
actual data from operations expressed in 
terms of views. We have already discussed 
the mapping mechanisms needed for one 
schema over a number of machines and 
have reviewed the mechanisms needed to 
support multiple schemas. The composition 
of these mechanisms does not pose intrinsic 
difficulty; for example, workers on Inria’s 
MRDSM did not report special problems 
in creating multiple schemas over several 
machines. 

In our view, the data parameter is com¬ 
pletely independent of the other parameters 
that compose a transaction processing 
system. The task of constructing and 
maintaining schemas is faced by imple¬ 
mented of database systems in general. 
Solutions they develop for databases extend 
to the more constrained transaction systems 
as well. For this reason, we also discussed 
techniques used to implement the data pa¬ 
rameter that were actually developed for 
the database systems rather than for the 
transaction processing systems. 

Single schema versus multiple schemas. 
To show the benefits of a multischema 
system, we analyze an alternative system 
— a single-schema system created from n 
distinct systems. Suppose data heteroge¬ 
neity originally existed in a system with 
the tuple (P x , M n , H x , D„ 5j), where each 
machine was originally a unimachine 
transaction processing system. When we 
link the machines in a multimachine system 
(M„, H x ), we construct the single schema in 
bottom-up fashion from local schemas that 
were supported at each machine. Con¬ 
struction of the single schema, or global 
schema, requires resolution of syntactic 
and semantic heterogeneity — definitely a 
nontrivial task. In the obvious case of data 
heterogeneity, the minimum information 
we require is the function mapping the 
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syntax of one machine’s data to another 
machine’s and the function mapping the 
semantics of one machine’s data model to 
another’s. In this section we discuss some 
of the mappings needed to resolve hetero¬ 
geneous data into a single data schema. 

Both research and implemented systems 
have followed the indirect mapping meth¬ 
od discussed above in mapping between 
the global and local schemas: They differ 
only in the system’s canonical model. These 
include the relational model, the entity- 
relationship model, and afunctional model. 
If two schemas are “equivalent” but use 
different data models, then mapping one 
schema into the other is not overly difficult. 
However, the notion of “equivalence” is 
difficult to formalize. Essentially it corre¬ 
sponds to what we have called syntactic 
conflict: When schemas are not equivalent, 
it is because they conflict semantically. 

It is not enough for the system to map 
local schemas (and queries) to the global 
schema (and global data language). The 
system must perform the reverse mapping 
— transform the global schema into local 
schemas to get data from the local nodes. 
The relational data model is not as ex¬ 
pressive as others, and therefore is not as 
helpful for integrating the component 
schemas. The flip side is that the relational 
model makes it easier to do query decom¬ 
position and other reverse transformations. 
This is why prototype systems such as 
System Development’s Mermaid and 
Amoco’s ADDS and the Preci* system 
adopted the relational approach. Multibase, 
on the other hand, completely redefines the 
local schemas into the functional data model 
(using Daplex). Then the local schemas are 
written in the same data definition lan¬ 
guage as the global schema, and mapping 
in both directions is easy. 

After the system maps local schemas 
residing on the system’s machines,into a 
single schema, it must ensure that no naming 
conflicts exist among the individual sche¬ 
mas. Homonyms are much easier to detect 


than synonyms because the system simply 
compares concepts possessing the same 
name across component schemas. The 
comparison requires human interaction, and 
designers often use the “universal relation 
schema” assumption: Every attribute is 
unique over all databases, and thus hom¬ 
onyms cannot arise. We can implement 
this assumption by simply preceding every 
object or attribute name with schema, for the 
ith schema. The detection of synonyms is 
more difficult because the system cannot 
even automatically flag possible occur¬ 
rences for human inspection, as it can for 
homonyms. Batini and Lenzerini’s inte¬ 
gration system automatically assigns to 
pairs of objects a “degree of similarity” 
based on various matching criteria. 11 The 
system then provides the similarity infor¬ 
mation to designers for their decisions. 

Once the system has dealt with syntactic 
conflicts between the component schemas, 
it must deal with semantic conflict. Even 
methodological treatments of this problem 
do not provide algorithmic specifications 
for the integration process. 9 Rather, they 
provide general guidelines and identify 
critical steps. Designers play a major role 
to the extent that while a methodology 
iterates, loop termination is left to their 
discretion. 

When the system detects schema con¬ 
flicts, designers must resolve them through 
schema transformation. Sometimes sche¬ 
mas do not actually contradict each other 
in their world view, but only express 
themselves differently. An example of this 
situation is the subset relationship we 
presented in our discussion of interschema 
diversity: The subset relation simply models 
multiple views about the same class of 
objects. By noting such interschema rela¬ 
tionships, the system can create a single 
richer view that encapsulates the concepts 
of the original component schemas. In other 
cases the schemas, when unified, contain 
redundant information. The system can 
detect and eliminate such redundancies as 
subsets, derived dependencies, composition 
of functions, and cycles of relationships. 
Of course, sometimes no resolution is 
possible because the same object has dif¬ 
ferent values in different schemas. Then 
designers must decide which schema 
“counts” and which does not. 

The literature does not explicitly deal 
with many semantic conflict transforma¬ 
tions. Batini and Lenzerini discuss atomic 
transformations, in which entities, at¬ 
tributes, and relationships are mapped one 
into the other until a canonical representa¬ 
tion of the schemas is achieved." Unfor- 
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tunately, such conflicts are more syntactic 
than semantic, because there is a very strong 
overlap between atomic concepts. 

The benefits of multiple schemas are 
tempered by a trade-off between system 
administrators’ effort and users’ effort. 
Managing a single schema is easier (in 
terms of defining the schema and then 
maintaining its consistency) than manag¬ 
ing multiple schemas. On the other hand, 
users do not want to be forced to compro¬ 
mise their world views in favor of a model 
that may not completely satisfy anyone. 
Certain semantic data modeling differences 
simply cannot be resolved except by arbi¬ 
trarily choosing one model. Then users 
have to do their own data filtering and 
management to keep the data consistent 
with their points of view. Requiring this 
runs counter to the idea that database sys¬ 
tems should remove the burden of data 
management from users and place it on 
database administrators. Moreover, users 
may not be able to do the filtering properly. 

This trade-off exists only in the context 
of schema maintenance. System designers 
concerned with schema creation may decide 
to build a D n system in which syntactic and 
semantic differences are explicit. When 
multiple schemas are already in the system, 
the difficulties inherent in their resolution 
may encourage designers to favor the 
multischema system, too. 

Multiple schemas and a data heteroge¬ 
neity metric. The transition from £>, to D„ 
in a transaction processing system does not 
necessarily indicate a system that supports 
heterogeneous data. For example, if sche¬ 
mas model disjoint parts of a user’s universe, 
the system incorporates a D n component. 
This instance of n cardinality is simply a 
function of schema granularity. In other 
words, because the schemas cannot be re¬ 
solved, the system in fact supports a single 
schema that is the trivial union of the in¬ 
dividual schemas. 

We can continue to use D, to express the 
case of systems with different virtual 
schemas. Such systems allow the creation 
of schemas that do not map directly onto 
the underlying physical data. Instead, the 
virtual schema is composed of various actual 
schemas supported by the system. However, 
all the virtual schemas are ultimately 
mapped into the single, underlying system 
schema, so the syntactic difference between 
views is insignificant compared with the 
equivalence-disjunction relationship 
holding among the schemas. 

When users cannot categorically state 
that a relation of equivalence (true or false) 
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exists among data, then the data are heter¬ 
ogeneous. Therefore, a multischema sys¬ 
tem has the potential of supporting hetero¬ 
geneous data. In fact, we can define 
heterogeneous data as data whose mainte¬ 
nance requires multiple schemas for their 
support: They are data that cannot be ex¬ 
pressed through a single schema. The 
syntactic-semantic continuum we presented 
earlier in a sense reflects the extent to 
which schemas cannot be resolved to a 
single schema without information loss. 

We need a metric for the notion that 
some types of data are more heterogeneous 
than others. For example, we can define on 
a continuum scale the difference between 
how two schemas model the world. In a 
system where either a single schema is 
available to users or user views can be 
trivially merged to a single schema, the 
difference is zero. The system thus sup¬ 
ports one view, so D, is the component in 
the tuple. In a system that can support 
virtual schemas, the difference is w°, indi¬ 
cating support for a minimal degree of 
heterogeneity. Although the syntax of the 
interfaces is the same, the world models 
represented by the schema are not exactly 
the same. In a system where the schemas 
return inconsistent values, the difference is 
n'. Such a metric lets us express interme¬ 
diate values between n° and n\ depending 
on whether the schemas differ syntactically 
or semantically. When the system supports 
more than two schemas, we can define the 
data heterogeneity as the maximum dif¬ 
ference between schemas. 

Site parameter. Two types of architec¬ 
ture are commonly identified in database 
systems comprising network-linked ma¬ 
chines. The first is a global (or centralized) 
database architecture, which imposes a 
global database control and communication 
system between users and the local data¬ 
bases. A global data model describes the 
overall meaning of the integrated compo¬ 
nent schemas; this model is often called the 


global schema, in analogy to local schemas. 
For the user, such a tightly coupled system 
is indistinguishable from a local component 
system. The second type of architecture 
provides a federated database system, 12 in 
which each component database determines 
the data it allows other sites to access (via 
export schemas). In turn, a component can 
access only the nonlocal data that other 
sites are willing to give it. However, once 
users have permission to access nonlocal 
data, they access (through their local site) 
heterogeneous and distributed data with 
complete transparency. Federated databases 
are thus loosely coupled systems. 13 

Database architectures need not be 
constrained by the number or type of log¬ 
ical schemas available to processes. The 
administrator of a centralized tightly cou¬ 
pled system can provide different classes 
of users with different views of the data. 
Then some users can see only local site 
data, but others see remote data as well. 
Similarly, the local administrator of a 
federated database can import sufficient 
remote data for users to construct integrated 
views from the entire system. Thus, users 
continue to see “their” data without regard 
to the underlying distributed or heteroge¬ 
neous system architecture. 

System architecture raises the question 
of how authority is distributed over the 
system. A transaction processing system 
maps processes onto the set of machines 
that support the system. But a real machine 
can easily support the mechanisms needed 
both to construct schemas and to map them 
onto data residing on the machine. In other 
words, an individual machine can support 
a system ( P x , M,, H x , Local-/),, Local-5,) 
and, at the same time, be an element of the 
overall set of machines, so that schemas 
different from local schemas are mapped 
onto it. An obvious conflict arises: Does 
the local site or does some other site con¬ 
trol data on the machine? For example, 
who determines data description or data 
usage? 

We call this issue local autonomy. The 
degree of local autonomy is the extent of a 
local site administrator’s control over his 
or her site when the site is part of a larger 
system. We can express the distribution of 
authority within the overall transaction 
processing system in terms of the number 
of sites in the system: Transaction pro¬ 
cessing systems are designed with either 
an 5, or S„ parameter. 

Because researchers use the term “site” 
in different ways, we make our terminol¬ 
ogy explicit. A site is a set of machines that 
is a subset of a larger set of machines which 
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make up the transaction processing system. 
Each machine in a site may contain data. 
The site also supports a set of schemas that 
are the only schemas directly available to 
the machines at the site. In other words, a 
given site controls access to any data re¬ 
siding on a machine that belongs to the site. 
Controlling access involves such schema 
maintenance operations as defining the 
logical world view of the schemas supported 
by the site, maintaining integrity constraints, 
and modifying the original schemas. When 
a transaction needs access to data belong¬ 
ing to a schema supported by a site, the site 
filters the access request and determines 
whether the transaction’s request (read or 
write) has been satisfied. 

Not all researchers share the view that 
site autonomy is linked with the issue of 
who controls schemas in the transaction 
processing system. The concept of system 
autonomy is receiving much attention in 
the literature and its definition is in flux. 6 
Some researchers distinguish between de¬ 
sign autonomy and execution autonomy. 
Design autonomy is equivalent to autono¬ 
my as we define it in this article. Design 
autonomy is exercised by the person who 
controls the design and maintains the data 
schemas. The term execution autonomy 
changes the focus to the question of whether 
local systems control local transaction 
execution or whether they accede to a global 
transaction coordinator that schedules and 
executes transactions. 

We believe that execution autonomy 
actually relates to the machine heterogeneity 
parameter, because before execution au¬ 
tonomy becomes an issue, techniques must 
be developed to coordinate global trans¬ 
actions among sites that want to cooperate 
but do not necessarily share the same 
transaction atomicity mechanisms. If de¬ 
signers relax the assumptions used by the 
global transaction algorithms, perhaps they 
can design the characteristics required of 
local systems to avoid infringing on local 
autonomy. 

The area of execution autonomy is cur¬ 
rently very active. Consequently, in ana¬ 
lyzing the site parameter, we focus on 
design autonomy. 

Multisite system autonomy. Until now, 
we have assumed that the site parameter in 
the transaction processing system is simply 
S’,. If site cardinality equals 1 (centralized 
architecture), local sites are completely 
integrated into the overall global system. 
The global database manager makes deci¬ 
sions about schema design and cannot al¬ 
low local sites any independence. Other¬ 


wise, actual data could reflect a world state 
different from the world state described by 
the global schema. A system with a cen¬ 
tralized architecture treats all transactions 
in the same manner because they all orig¬ 
inate “inside” the system. 

When a number of sites exist within the 
system, a single site can be certain of ac¬ 
cess only to data belonging to a schema 
supported by the site itself. If a transaction 
needs access to data belonging to a schema 
supported by another site, then (by the very 
definition of a site) the site running the 
transaction must “negotiate” with the site 
owning the data for access to that data. 
There is a distinction between local trans¬ 
actions, about which the site knows all 
relevant information, and remote transac¬ 
tions, where the site must get its informa¬ 
tion from another site. 

When site cardinality is greater than 1, 
designers can realize a federated database 
architecture to allow local sites consider¬ 
ably more autonomy in operating their sites. 
If one site’s world model is different from 
another site’s world model, it simply refuses 
to let the foreign data into its system. 
Similarly, catalog design, naming schemes, 
and user authorization are handled inde¬ 
pendently in a federated system. In contrast, 
an integrated system has to make and en¬ 
force these decisions in all-or-none fashion. 
A federated system can use systemwide 
names, so local data references can be 
performed locally while a remote reference 
requests data from a foreign site. IBM’s R* 
uses such an approach. Of course, the (P x , 
M„, H„ D n , S n ) tuple accommodates a sys¬ 
tem with a mixed architecture. Several 
machines could make up a site’s machine 
set. If the site allows them access only to 
certain schemas, then the machines resemble 
a global database system. At the same time, 
other machines could belong to other sites, 
so the overall transaction processing sys¬ 
tem looks like a federated system. 

Inserting local autonomy into a system 
is primarily a political decision about the 
distribution of power within the database. 
Autonomy can interact with the data di¬ 
mension in a system put together from a set 
of existing databases. Earlier we described 
the differences between single-schema and 
multischema systems and the difficulties 
involved in creating a single global schema 
from a number of local schemas. When 
sites possess local autonomy, there is usually 
no option: Users at each site will insist on 
the validity of their site’s schema. Then 
putting the system together is easier because 
designers avoid decisions about syntactic 
and semantic consistency. 


However, effectively using such a mul¬ 
tisite, multischema system can be very 
difficult. For example, telling users what 
data is available — and where — is non¬ 
trivial in an autonomous system. Moreover, 
such systems do not easily support repli¬ 
cation. Replication implies that data under 
a given site’s control are logically the same 
data mapped to a schema under the control 
of another site. For the second site to benefit 
from such replication, the first site must 
treat its data the way the second site treats 
its own data. Such a guarantee is impossible 
because the two sites are autonomous. The 
best that can happen is that different sites 
make “pacts” with one another — a task 
that requires much coordination. Export 
schemas often formalize such pacts: Each 
site defines the part of its database that it is 
willing to share with the rest of the feder¬ 
ated database. 1214 We address this issue 
further in a later section. 

Multiple sites and a single machine. Is¬ 
sues involving sites and autonomy make 
sense in the context of multiple machines 
supporting multiple data schemas. But what 
happens in a system in which multiple sites 
support multiple schemas — but on one 
machine? At first glance an (M,, S„) system 
seems impossible: Each site should have at 
least one machine, so how can multiple 
sites be mapped onto one machine? In fact, 
a single real machine can simulate several 
machines by time-slicing the CPU and 
partitioning the address space. 

Putting several sites on a single machine 
increases security. Just as administrators 
can create classes of users by assigning 
each class a distinct schema, they can further 
separate classes of users by assigning each 
to a different site. Sites provide local au¬ 
tonomy, so the fire walls are stronger than 
those provided by multiple schemas sup¬ 
ported by a single common site. With R* 
designers can construct such a system. 

Multiple sites and a single data schema. 
Transaction processing systems can be 
designed so that multiple sites support a 
single common schema on the system. The 
implications of several sites supporting a 
single schema are subtle. The sites are 
committed to a common logical view of the 
world, and only one mapping maps logical 
data to physical data; that is, a unique and 
consistent value is returned for every data 
reference. Therefore, the intrinsic property 
of multiple sites — local autonomy — is 
precluded simply because the sites have 
agreed to use a single schema. Sites can 
access all data belonging to their schema, 
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and their schema comprises all the data in 
the system. Similarly, because integrity 
constraints are part of the logical schema, 
one site cannot allow a value assignment 
that another site would disallow. Thus, 
systems that combine a D, component with 
an S„ component are philosophically in¬ 
consistent because the management aims 
implied by site autonomy cannot be realized 
in a system limited to only one schema. 


Systems evolution 

In this section we discuss the way 
transaction processing systems have 
evolved in terms of the system dimensions 
that we have identified: the process, ma¬ 
chine, heterogeneity, data, and site com¬ 
ponents. The overall configuration of any 
transaction processing system has a specific 
value for each of the five components. The 
set of processes execute on a set of machines 
(with a certain degree of heterogeneity 
between the machines) in a way that 
maintains concurrency and recovery ato¬ 
micity. Physical data reside on the machines; 
sites are responsible for maintaining the 
mapping between requests for logical data 
to this physical data. 

For database systems to be useful as 
transaction processing systems, they must 
be able to run more than one process con¬ 
currently (the cardinality of P must be 
greater than 1). Therefore, we ignore the 
process parameter and assume that systems 
all have a P„ component. 

Also, according to our model, systems 
evolution has nothing to do with the issue 
of autonomy (the cardinality of 5). 
Whether to provide site autonomy is pri¬ 
marily a political decision in which site 
autonomy is neither an improvement or an 
extension. Providing site autonomy in a 
global transaction processing system is very 
difficult and only recently has come under 
intensive research. Therefore, we do not 
emphasize the dimension of autonomy in 
describing systems evolution. 

We can represent any transaction pro¬ 
cessing system as a point in a three-di¬ 
mensional space whose axes stand for three 
of the four parameters presented in this 
article: data, machine, heterogeneity, and 
site. In Figures 3 and 4, we mark the data 
axis with single schema, views, and multi¬ 
schema to represent the evolution of data 
heterogeneity. In Figure 3, we mark the 
machine axis with unimachine and multi¬ 
machine to represent the evolution of the 
machine parameter. The site axis is simply 
marked with autonomy and no autonomy 


(Machine) 



Figure 3. System evolution along the machine, data, and autonomy dimensions. 



Figure 4. System evolution along the machine heterogeneity, data, and autonomy 
dimensions. 
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(Figures 3 and 4), and the heterogeneity 
axis with homogeneous and heterogeneous 
(Figure 4). 

The origin in Figures 3 and 4 indicates 
the point ( P „, M,, H t , £),, 5,) and represents 
a base system with simple properties. First 
we discuss the base system; then we trace 
system evolution along the various dimen¬ 
sions, using actual transaction processing 
systems as examples. The open areas of the 
graph show characteristics that pose par¬ 
ticularly difficult problems, which re¬ 
searchers are only beginning to address. 

Table 1 lists the systems we describe and 
their values for each of the five system 
characteristics. More details about some of 
these systems are available in the referenc¬ 
es cited by Ceri and Pelagatti. 15 We do not 
discuss commercial transaction process¬ 
ing systems because the specific aspects of 
these systems are not readily available or 
they are too detailed for this article. A 
recent survey of heterogeneous distributed 
database systems for production use pro¬ 
vides information about some commercial 
systems. 14 

Starting point. The origin represents 
base transaction processing systems that 
run on one machine and support only one 
view of data. A single-processor machine 
is the natural building block for the base 
system. Such systems present the user with 
a single view that represents the “union”— 
in fact, the natural join — of the underlying 
relations. 

Although virtual views are useful for 
simplifying interaction with system data, 
updating databases through views poses 
problems on base systems. For users to 
modify the underlying data (update, inser¬ 
tion, or deletion) via views, the system 
must express the modification in terms of 
the actual schema and data. Often it must 
create null values, thus introducing com¬ 
plications in later database access. These 
difficulties are surmountable, but a base 
system naturally supports only a single 
view. A fragmentation mechanism can 
partition the overall schema into disjoint 
components, enabling greater security. 

An example of a base system is Sys- 
tem/U (developed at Stanford University 
in the early 1980s), which uses the uni¬ 
versal relation model. 

Data dimension. Figure 3 shows evolu¬ 
tion from the base system along the data 
axis, maintaining the unimachine value 
along the machine axis. Because of the way 
unimachines usually operate, the site value 
is no autonomy. 


As database systems 
evolved, they no longer 
required that the 
underlying local 
databases be similar. 


Although a single schema and data map¬ 
ping are the easiest data components to 
support, they are less useful as more users 
access the system, or when system data is 
created and maintained by multiple sourc¬ 
es. Then a single view is an inaccurate 
model of the multiple views that users have 
of the external world. Thus, as systems 
evolve, they tend to support the definition 
of virtual views, produced as a result rela¬ 
tion from one or more operand relations 
operated on by a select statement. Virtual 
views let users tailor their approach to the 
system’s data. Mappings between actual 
data and the logical schema interface are, 
of course, more complex. The use and 
definition of such views was first support¬ 
ed in the SQL language. Unimachine sys¬ 
tems supporting this degree of data hetero¬ 
geneity include IBM’s System R (developed 
in the late 1970s) and Ingres (developed at 
the University of California at Berkeley in 
the early 1970s). These systems lie farther 
along the data axis in Figure 3, as we hold 
the machine value constant. 

Although multiple schemas can be 
maintained by a single site, in practice 
systems that support multiple schemas have 
done so in the context of maintaining au¬ 
tonomy among multiple machines. As a 
result, we do not place any points farther 
along the data axis. 

Machine dimension. Transaction pro¬ 
cessing systems running on one machine 
evolve naturally into multimachine sys¬ 
tems to provide better response time, reli¬ 
ability, and availability. The difficulty is 
that mechanisms (for example, logging), 
protocols (two-phase commit), and map¬ 
pings (data definition, replication, and 
fragmentation) must be coordinated among 
the machines to maintain atomicity, serial- 
izability, and data integrity for global pro¬ 
cesses. Coordination is difficult enough, 
so designers avoid as much as possible the 
additional mapping problems introduced 
by heterogeneity. 


The bare-bones multimachine system 
presents a single logical schema to the 
user. A coordinator with access to the 
necessary global information maps pro¬ 
cesses onto a set of identical or nearly 
identical machines. To represent such 
systems, we hold the data value at single 
schema. Examples include Computer Corp. 
of America’s SDD-1 (a prototype system 
developed in the early 1980s) and Porel 
(developed at the University of Stuttgart 
in the early 1980s). 

To represent systems that support user- 
defined views while maintaining location 
transparency (which allows users to treat 
the system essentially as a unimachine 
system), we hold the machine value con¬ 
stant and change the data value to views. 
These systems must properly distribute 
among machines such information as 
names, integrity constraints, and values. 
Very different approaches have been pro¬ 
posed. Systems such as SDD-1 and Dis¬ 
tributed Ingres (also developed at the Uni¬ 
versity of California at Berkeley) require 
that all information on all machines be 
available in managing the data. Because 
they do not allow individual sites any 
autonomy, approaches such as centralized 
catalogs are possible. 

Moving up the site axis in Figure 3 to 
the value of autonomy, we see systems such 
as IBM’s R* (developed in the early 1980s) 
that support autonomy to the extent that 
each site can modify all the previously 
mentioned information without accessing 
any information stored at other sites. 

Machine heterogeneity dimension. As 

database systems evolved, they no longer 
required that the underlying local data¬ 
bases be similar. Such systems are often 
constructed from existing components (H n ), 
which can differ widely in the DBMSs 
managing individual systems. In Figure 4 
we replace the machine axis with the ma¬ 
chine heterogeneity axis and examine sys¬ 
tems running on multiple machines. Earli¬ 
er in the article, we presented various 
approaches to the problem of integrating 
systems. The approach of composing lo¬ 
cal system transaction functionality into 
global functionality may be implemented 
in future systems. However, the solution 
in current systems (such as heterogeneous 
Sirius-Delta, developed at Inria in the ear¬ 
ly 1980s) is to define a set of common 
functions that each participating DBMS 
in the overall system must provide. The 
requisite redesign of software can be con¬ 
siderable. In a sense, this approach solves 
the problem of heterogeneity by insisting 
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on homogeneity. Such a system has never¬ 
theless evolved from truly homogeneous 
machines, but more evolution along the 
machine heterogeneity dimension in fu¬ 
ture products may make such solutions 
obsolete. 

An increased degree of machine hetero¬ 
geneity in the system is orthogonal to the 
nature of the data component. Once the 
data distribution mechanisms are in place, 
they are at a level high enough to be unaf¬ 
fected by changes in DBMSs. In fact, the 
multilevel schema architecture of hetero¬ 
geneous Sirius-Delta is unchanged from 
that of homogeneous Sirius-Delta (devel¬ 
oped in the late 1970s). Of course, lower 
level heterogeneity (for example, in the 
operating systems) complicates the map¬ 
ping mechanisms needed to manage data, 
unless the local DBMSs present a homoge¬ 
neous interface. Sirius-Delta has a heter¬ 
ogeneous value on the heterogeneity axis, 
and a views value on the data axis. Because 
machine heterogeneity is a relatively re¬ 
cent feature of actual systems, systems 
skip over the stage of having a single 
schema and instead incorporate more so¬ 
phisticated data components, such as vir¬ 
tual views. 

We see a similar incorporation tendency 
in the data dimension. Nowadays, design¬ 
ers generally construct systems bottom-up 
because heterogeneous components already 
in use represent too much investment to be 
eliminated for a new system. Also, because 
of their specialization, heterogeneous 
components can give increased function¬ 
ality to the overall system. To engineer a 
bottom-up approach that composes indi¬ 
vidual pieces into a larger system, design¬ 
ers must develop techniques to systemat¬ 
ically incorporate local schemas and data, 
which are almost always heterogeneous. 

Earlier we said that machine heteroge¬ 
neity in implemented systems tends to be 
resolved by imposing a homogeneous in¬ 
terface. Similarly, systems composed of 
heterogeneous data components map the 
local data models to a common interface 
— a process that requires conversion of the 
local data schemas. Designers resolve data 
heterogeneity using techniques described 
in the section on multischema systems, 
and the system presents a single global 
schema to the user. Because their data 
resolution mappings are very complex, we 
place systems such as Preci* and NDMS 
farther to the right on the data axis than 
Sirius-Delta (Figure 4). These systems re¬ 
solve data heterogeneity into a single, 
common interface (the canonical and rela¬ 
tional data models respectively), so they 



Systems that support 
multiple schemas were 
developed partly to 
maintain local 
autonomy. 


do not have the multiple schema data 

Site dimension. Some systems with the 
multischema value on the data axis require 
no conversion of the local schemas. For 
example, Inria’s MRDSM (developed in 
the mid-1980s) lets users create individual 
schemas composed of elements from local 
database schemas. Systems that support 
multiple schemas were developed partly to 
maintain local autonomy. System design¬ 
ers have a choice between integrating com¬ 
ponent schemas into a single global sche¬ 
ma or retaining the local schemas and 
somehow getting global functionality. Thus, 
the data parameter interacts with the site 
parameter: If the system allows site auton¬ 
omy, system designers cannot interfere with 
local schemas. 

MRDSM’s approach of allowing users 
to customize their individual schemas from 
any schemas in the system has obvious 
advantages. To construct these schemas, 
users must identify and resolve syntactic 
heterogeneity and semantic heterogeneity, 
and then build and maintain the custom¬ 
ized schemas. Each step is formidable. 

How does MRDSM implement multiple 
schemas? The component databases oper¬ 
ate the same relational MRDS DBMS, so 
the system must deal only with semantic 
heterogeneity. When users create their in¬ 
tegrated global schemas, they must also 
create dependency schemas with informa¬ 
tion relating component databases to each 
other. The process is delicate, and a more 
automated mapping mechanism between 
local databases and a given global schema 
would be helpful. Moreover, the effects of 
component database changes on users’ 
existing conceptual schemas are not clear. 
Creating views is not very difficult, but 
propagating updates (expressed in terms of 
user views) to the underlying real schema 
is much harder, especially because the 
component sites are allowed full autono¬ 
my. Also, MRDSM decomposes queries 


formulated in terms of users’ conceptual 
schemas into queries on component data¬ 
bases, and then gathers the data into a 
working database. This requires much ef¬ 
fort in recompilation for fairly trivial mod¬ 
ifications to the underlying databases. 

The MRDSM approach is not complete¬ 
ly adequate, but the system is one of the 
few that support multiple schemas and site 
autonomy. 

Open areas. Figures 3 and 4 have some 
open areas. One is on the multischema 
sector of the data axis. Efficient design and 
maintenance of a multischema system is 
difficult. The problem is compounded when 
designers try to maintain local site auton¬ 
omy. The system must build schemas from 
local schemas, while users can modify Id¬ 
eal schemas at will. 

Another open area is the autonomy sector 
of the site axis. In this article, we consid¬ 
ered autonomy from the design viewpoint 
— who controls design and access to 
schemas? Thus, we cite R* as a system that 
supports autonomy: Its flexible naming 
scheme lets sites rename relations without 
coordinating the activity with a central 
authority. However, autonomy involves 
other issues such as execution autonomy, 
which calls the entire notion of a transac¬ 
tion processing system into question. Re¬ 
searchers are beginning to address associ¬ 
ated questions: 

• Must participating sites sacrifice in- 
dependencejustto implement a globally 
serializable transaction schedule? 

• Can autonomy be defined with suffi¬ 
ciently fine granularity so that designers 
can build transaction processing sys¬ 
tems that provide flexibility in assigning 
autonomy? 

Answers to these questions will help deter¬ 
mine whether the open areas in Figures 3 
and 4 are filled in the next decade. 


U sing the dimensions of processes, 
machines, machine heterogene¬ 
ity, data schemas, and sites, our 
classification system focuses on issues 
common to transaction processing systems. 
We can give the dimensions values to cap¬ 
ture the essential features of any transac¬ 
tion processing system and compare it with 
others. Our comparison and evaluation of 
transaction processing systems reveal evo¬ 
lutionary paths along the dimensions of 
data schema heterogeneity and machine 
heterogeneity. ■ 
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Expanded investigation adds to Prodigy’s woes 

Bob Carlson, Staff Editor 


Already under investigation by the 
Consumer Protection Division of the Los 
Angeles County District Attorney’s Of¬ 
fice over alteration of its flat-rate policy, 
Prodigy Services now faces an investiga¬ 
tion into complaints involving unautho¬ 
rized access to the files of its subscribers. 

A Prodigy subscriber first became con¬ 
cerned when she discovered that one of 
the files Prodigy software created had 
copied portions of source code for a pro¬ 
gram she had been writing herself. Other 
subscribers claim to have found pieces of 
their files in the STAGE.DAT file creat¬ 
ed by Prodigy and used in the installation 
process. 

Company officials have stated that 
Prodigy software does not have the capa- 


A new computer using thousands of 
parallel processors to analyze and render 
the shapes of three-dimensional objects 
has been developed by researchers at 
Duke and Cornell Universities. 

According to the National Science 
Foundation, which funded the research¬ 
ers, the Ray-Casting Engine is relatively 
inexpensive and could profoundly affect 
the field of mechanical design, rapidly 
producing mathematical models of com¬ 
plex geometrical shapes such as machine 
parts. Its designers believe that a com¬ 
mercial version could be available in a 
few years and cost less than $100,000. 

Traditional approaches to solid model¬ 
ing, such as serial calculations on super¬ 
computers and the programming of exist- 

IEEE members sought to 
high school students 

IEEE-USA’s Precollege Education 
Committee is establishing a discipline- 
based volunteer student guidance net¬ 
work and is looking for volunteers will¬ 
ing to serve as resource persons by 
responding to occasional requests for ca¬ 
reer information in a specified area of 


bility to read subscribers’ files and that 
they have no interest in what anyone has 
on their hard disks. 

Computerworld' s Christopher 
Lindquist reported two possible explana¬ 
tions for what subscribers claim has oc¬ 
curred, as provided by Harold Goldes, a 
Prodigy program manager. Data already 
present in the computer’s memory may 
have been incorporated when the instal¬ 
lation program created the STAGE.DAT 
file, or the contents of previously “delet¬ 
ed” files may have been in the disk 
space allocated to but not used by 
STAGE.DAT. 

The accidental introduction of extrane¬ 
ous data into a file in such a manner 
would not be unique. The complaints in 


ing general-purpose parallel computers, 
have often been too slow or too expen¬ 
sive. The Duke-Cornell team designed 
their application-specific computer to 
closely match the computational structure. 

The Ray-Casting Engine allows ma¬ 
chines to be built at multiple levels of 
performance by scaling the number of 
processors. The research team plans to 
explore ways to integrate the Ray-Cast¬ 
ing Engine into existing commercial 
modelers. 

John Ellis and Gershon Kedem of 
Duke University and Richard Marisa, Jai 
Menon, and Herb Voelcker of Cornell 
University described the research in an 
article published in the February 1991 is¬ 
sue of Mechanical Engineering magazine. 


counsel 


expertise. The discipline areas to be cov¬ 
ered are electrical, electronics, and com¬ 
puter engineering. 

For more information, contact A. 
Hartfiel, IEEE-USA, 1828 L St. NW, 
Suite 1202, Washington, DC 20036, 
phone (202) 785-0017. 


this case are probably indicative of in¬ 
creasing awareness about privacy issues 
throughout the user community. But the 
level of security many users desire is ex¬ 
tremely hard — if not impossible — to 
obtain in personal computers linked to 
the outside world via modem. 

Security experts commenting on the 
case generally see no evidence of wrong¬ 
doing on the part of Prodigy but take the 
occasion to point out that threats to data 
security abound and are more serious and 
diverse than many users realize. 

Meanwhile, Los Angeles County offi¬ 
cials plan to proceed with the investiga¬ 
tion. Deputy District Attorney Richard de 
la Sota told the Los Angeles Times that 
Prodigy potentially could be charged 
with violating the state penal code sec¬ 
tion that prohibits unauthorized access to 
computer systems and data. Or, he add¬ 
ed, the firm could be exonerated. 


Unix goes to Prague 

AT&T, with the aid of SOKOL, the 
Czechoslovakian relief organization in 
New York City, donated 25 AT&T 3B2 
Unix computers, 70 AT&T terminals, 12 
AT&T Paradyne modems, and a full 
complement of Unix SVR3 software and 
applications to three Czechoslovakian 
educational institutions. The computers 
will be used by mathematics and comput¬ 
ing departments at Charles University, 
Prague; Masaryk University, Brno; and 
Comenius University, Bratislava. 

Karel Janac, Michael Potmesil, and 
Ralph Severini of AT&T Bell Laborato¬ 
ries began the project shortly after the 
Berlin Wall fell and the “velvet revolu¬ 
tion” occurred in Czechoslovakia. The 
possibility of the computer transfer be¬ 
came a reality with the reduction in tech¬ 
nological trade restrictions negotiated by 
the European Economic Community in 
June 1990. 

Several university members are ex¬ 
pected to attend Unix classes and semi¬ 
nars. One representative from Masaryk 
University already spent a month in the 
US getting hands-on Unix experience. 


Parallel computer specializes in 3D modeling 
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Chip uses light instead 
of electrons for off-chip 
communications 

Researchers at Texas Instruments have 
developed and demonstrated a highly in¬ 
tegrated microchip that is targeted to 
transmit information between chips using 
light instead of electrons and copper 
wire. The technique could dramatically 
boost computing speed when incorporat¬ 
ed into working systems, perhaps in the 
next five to 10 years. 

TI feels that many of the most chal¬ 
lenging barriers to computer perfor¬ 
mance lie not in the chips themselves but 
in the way chip packages are mounted on 
printed circuit boards and connected with 
one another. James Yuan, a TI research 
manager directing work on alternatives 
to traditional interconnect technologies, 
points to the fundamental physical limi¬ 
tations of copper. “These factors create 
bottlenecks that can shackle the perfor¬ 
mance of very fast, very complex chips,” 
he said. 

Speed, space, power advantages. Be¬ 
cause of the speed advantage light holds 
over electrons, one optical interconnect 
could replace as many as 32 pins in a 
conventional chip package, TI said. And, 
of course, high-speed optical connections 
can be packed more densely on a circuit 
board. 

Experts have estimated that existing 
optical interconnects used for computer- 
backplane applications require approxi¬ 
mately 20 percent less board space and 
use 20 percent less power than function¬ 
ally equivalent electrical interconnects. 
For monolithic integrated optical cir¬ 
cuits, the power savings could be consid¬ 
erably higher. 

GaAs on silicon. According to TI, the 
device — an optoelectronic integrated 
circuit, or OEIC — is the first monolithic 
integrated circuit to combine silicon 
CMOS logic circuitry with an array of 
eight gallium arsenide infrared light- 
emitting diodes. 

Because traditional silicon and GaAs 
manufacturing techniques are incompati¬ 
ble, TI produced the monolithic OEIC 
using a co-integration process called gal¬ 
lium arsenide on silicon, developed in its 
Dallas research labs and first demonstrat¬ 
ed in 1988. 

“Now that we’ve proven the feasibility 
of integrating practical, high-perfor¬ 
mance silicon and GaAs circuitry in a 
monolithic form, we must address pack¬ 
aging and assembly issues,” Yuan said. 

“It remains to be seen how we can best 
use OEICs to transmit and receive infor¬ 
mation between chips.” 
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TC helps promote competition 
for aiding the disabled 


The IEEE Computer Society’s Tech¬ 
nical Committee on Computing and 
Persons with Disabilities (formerly 
Computing and the Handicapped) is 
participating in Johns Hopkins Univer¬ 
sity’s national search for computing 
technologies to assist people with dis¬ 
abilities. TC Chair James Caldwell, an 
IBM engineer, is serving on the pro¬ 
gram’s advisory board. 

“This is a good time to get involved 
with the TC,” Caldwell said. “We are re¬ 
cruiting for members, and I would like 
very much to hear ideas from volunteers 
who might like to participate.” In the 
past, members of the TC have been in¬ 
volved in text-to-voice, voice recogni¬ 
tion, expert systems, robotics, signal pro¬ 
cessing, and other emerging applications 
that should be available to the disabled 
and elderly. 

The Johns Hopkins search is a compe¬ 
tition for ideas, systems, devices, and 
computer programs designed to help the 
more than 25 million Americans with 
disabilities. The competition is open to 
all residents of the United States — stu¬ 
dents, amateurs, and computer profes¬ 
sionals alike. 

Regional competitions and exhibitions 
will be held across the country through¬ 
out 1991. Regional winners will compete 
for the $10,000 grand prize at the nation¬ 
al exhibit, to be held at the Smithsonian 


Institution in Washington, DC, February 
1-2, 1992. 

“Putting ingenuity and technology to 
work for people is our primary goal,” 
said Paul Hazan, project director for the 
search. “Through this search, computer 
professionals have a unique opportunity 
to apply their creativity and expertise to 
address urgent human needs and make a 
significant difference,” he said. “Appli¬ 
cations are limited only by the imagina¬ 
tion of the designer.” 

Ten years ago Johns Hopkins and its 
sponsor, the National Science Founda¬ 
tion, conducted a similar search that 
drew more than 8,000 participants. Rea¬ 
sonably priced communications devices 
and aids for environmental control, many 
of which received regional and national 
awards, subsequently became standard 
equipment for thousands of users with 
physical disabilities. 

Entries are due August 23, 1991. All 
invention rights will remain with the 
contestant. For more information about 
the competition, write to Computing to 
Assist Persons with Disabilities, Johns 
Hopkins National Search, PO Box 1200, 
Laurel, MD 20723. 

To learn more about the Technical 
Committee on Computing and Persons 
with Disabilities, contact James Cald¬ 
well, phone (512) 823-8184, e-mail 
caldwell @ ausvmr.vnet.ibm.com. 


IEEE Software honored by 
Computer Press Association 


IEEE Software, an IEEE Computer So¬ 
ciety publication, has been honored for 
excellence by the Computer Press Asso¬ 
ciation. In its sixth annual Computer 
Press Awards, the association named 
IEEE Software runner-up for best com¬ 
puter magazine with a circulation of less 
than 50,000. 

The judges commended IEEE Soft¬ 
ware for its “consummate technical con¬ 
tent presented in an understandable for¬ 
mat. Technical and scientific writing at 
its best, . . . IEEE Software presents large 
volumes of technical information with 
editorial flair. Editing is tight, design is 


fresh, illustrations have a point of view.” 

The Computer Press Association is an 
international organization of computer 
journalists, and awards are determined 
through a juried competition. IEEE Soft¬ 
ware was the only publication published 
by a professional association to be hon¬ 
ored in any of the Computer Press 
Awards’ 19 categories. 

The Computer Press Awards, cospon¬ 
sored by the Computer Press Association 
and Citizen America, honor excellence in 
computing-oriented journalism in the 
general and trade press, including print 
and broadcast media. 
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Printer sharpens images 

Hewlett-Packard’s HP Laser Jet Illsi 
300-dpi desktop printer offers an opti¬ 
mum throughput of 17 pages per minute. 

The printer creates images from toner 
particles approximately half the size of 
those on other 300-dpi laser printers, re¬ 
sulting in sharper images and less toner 
scatter, according to the company. 

The HP Laser Jet Illsi comes with two 
500-sheet input trays and a 50-sheet out¬ 
put tray. It is intended for a volume of up 
to 50,000 pages per month. 

The PCL 5 printer language, along 
with a RISC-based formatter, allows 
scalability for 13 resident typefaces. 
HP-GL/2 vector graphics provides soft¬ 
ware support. 

Available options include duplex 
printing; legal, executive, and A4 paper 
trays; up to 16 Mbytes of additional 
memory; a network printer interface; and 
integrated Adobe Postscript. 

The basic printer with resolution en¬ 
hancement and the HP PCL 5 printer lan¬ 
guage costs $5,495. With factory-installed 
Postscript and 2 Mbytes of printer mem¬ 
ory, the price is $6,595. The “microfine” 
toner cartridges cost $169 and are de¬ 
signed to print up to 8,000 pages. 
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User can control graphical 
displays 

Kinesix has developed Sammi, a 
Unix-based graphical user environment 
(GUE). The software lets users develop 
and customize graphical displays without 
performing application coding. 

Sammi operates under the X Window 
System, Version 11, as a stand-alone task 
that is configured and linked to applica¬ 
tions and databases via a network inter¬ 
face. 

The package runs on Sun Microsys¬ 
tems, Digital Equipment Corp., IBM, and 
Hewlett-Packard workstations. 

Initial development copies of Sammi 
range from $12,500 to $25,000, depend¬ 
ing on configuration. 
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The HP Laser Jet Illsi printer places 
portrait, landscape, reverse portrait, 
and reverse landscape images on the 
same page. 


High-resolutioncolor for 
flat square monitors 

Toshiba America claims its two flat 
square (FS) monitors reduce visual pat¬ 
tern distortion. 

The 17- and the 21-in. monitors pro¬ 
vide scanning capabilities from 30 kHz 
to 65 kHz (horizontal) and 50 Hz to 90 
Hz (vertical), and receive signals from 
VGA to high-resolution graphics. 

The FS screens use Toshiba’s Dynam¬ 
ic Astigmatism Control focus system and 
display resolutions up to 1,280 pixels x 
1,024 lines. 

The 17-in. model costs $2,100, and the 
21-in. model is $3,500. 
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Parsytec Inc. introduces the Multiple 
Virtual Machine Architecture as the basis 
for its transputer-based multicluster and 
supercluster series of parallel processing 
machines. The architecture’s open, mod¬ 
ular design lets users configure process¬ 
ing power and I/O capabilities for any 
application. 

Machines based on this virtual archi¬ 
tecture let a user perform real-time image 
processing while another portion of the 


Talk to your workstation 

Voice Dynamics Corp. has developed 
Microdyn II, a voice recognition system 
that enables CAD/CAM operators to is¬ 
sue verbal commands to the computer 
while creating drawings. 

Up to 1,000 voice commands can re¬ 
place keyboard strokes, mouse clicks, 
and digitizing tablet selections. 

The system functions on stand-alone 
workstations, local area networks, and 
multiuser systems operating with MS- 
DOS or OS/2. It is compatible with 286, 
386, 486, 8086, and 8088 systems, uses 
5 Kbytes of RAM, does not require hard¬ 
ware configuration changes, and works 
with most monitors. It contains its own 
microprocessor and plugs into the stan¬ 
dard RS-232 serial port on the computer. 


Reader Service 39 



The Microdyn II accepts verbal input, 
provides text-to-speech output, verifies 
commands, and verbally prompts the 
operator. 


processor pool is free for static number 
crunching. 

Multiple virtual machines run under 
Helios, the Multitool transputer develop¬ 
ment system, and cross compilers using 
MS-DOS, the Apple operating system, 
and Sun Unix. Language support in¬ 
cludes C, Par.C, Fortran, Pascal, Occam, 
and Ada. 
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Scalable architecture implemented 
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Need more RISC power? 


Sanyo Icon’s 88open Series of com¬ 
puters is RISC (reduced instruction-set 
computing) based and can serve up to 
250 users in native Pick and Unix appli¬ 
cation environments. 

The systems are based on the Motorola 
88100 32-bit RISC chip set, which is 
rated at a processing speed of 27 MIPS 
(million instructions per second) and 
provides three to five times the perfor¬ 
mance of standard complex instruction 
set computers. 

Up to nine additional Motorola 68000 


family coprocessors are used in each sys¬ 
tem to manage disk input/output, disk 
caching, printers, and terminals. 

Maximum capacity is currently 128 
Mbytes of on-board main memory and an 
unformatted disk capacity of up to 44.4 
Gbytes per system, using either SCSI 
(Small Computer Systems Interface) or 
HSM (High-Speed Memory) disk drives. 

The systems provide for internal instal¬ 
lation of industry-standard half-inch tape 
drives and support optional high-density 
cartridge and cassette tape backups. 


A DOS connectivity option is also avail¬ 
able for users. 

An entry-level 88open system, includ¬ 
ing tower enclosure, an 88000 processor, 
10 Mbytes of main memory, a 383- 
Mbyte disk drive, a tape backup, soft¬ 
ware licenses, and interfacing for 16 ter¬ 
minals is priced at $38,514. 

A comparable full-height cabinet ver¬ 
sion with half-inch tape drive and expand¬ 
ability to 250 users starts at $113,048. 
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How portable can you get? 


PC power in a palmtop 

Hewlett-Packard and Lotus have 
co- developed the HP 95LX, a palm¬ 
top computer with the PC XT archi¬ 
tecture. In addition to Lotus 1-2-3 Re¬ 
lease 2.2 and MS-DOS 3.22, the 
11-oz. PC features one-key access to 
applications, built-in organizer tools, 
support for third-party applications, 
and communications capabilities. 

Built-in software is executable 
from ROM. Users can print data from 
HP 95LX applications to HP Laser 
Jet, IBM Proprinter, and Epson FX-80 
printers. 

The optional HP FI001A connec¬ 
tivity packet provides bidirectional 
file transfer between the HP 95LX 
and desktop PCs. 



The HP 95LX palmtop PC trans¬ 
fers files to an IBM PC through its 
serial interface port. 


The palmtop has an 80C88-compati- 
ble NEC V20H CPU, 1 Mbyte of ROM, 
512 Kbytes of RAM, a 16-line by 40- 
character supertwist LCD, an industry- 
standard expansion-card slot, a QWER¬ 
TY keyboard with separate numeric 
keypad, and an optional AC adapter. 

The HP 95LX palmtop PC costs 
$699, the connectivity packet $99.95, 
the 128-Kbyte RAM card $199.95, and 
the 512-Kbyte RAM card $399.95. 
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When you need free hands 

Park Engineering has developed 
Compcap, a 1-lb. computer you can wear 
on your head. This portable can assist 
workers in the field who need high mo¬ 
bility. 

The PC-compatible Compcap, which 
reputedly offers the speed and processing 
power of a 386 desktop, comes in two 
models: a hard hat that incorporates the 
electronics, and a soft band worn around 
the head or hat with electronics built into 
a belt or vest. The device offers 4 
Mbytes of RAM with memory-card inter¬ 
face, custom keypad interface, and bar¬ 
code reader options. 

Reflection Technology’s 2-oz. Private 
Eye provides the miniature display. Its 
virtual screen projects images that appear 
to float a few feet in front of the user. 

The Compcap lets users interact with 
the device via a voice data-entry system. 

The ultraportable is priced from 
$1,500 to $3,000, depending on configu¬ 
ration and quantity. 


A Desk Top Development Kit is 
also available for $3,995, for custom 
prototyping of Compcap applications. 
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A mouse for laptops 

The Icontroller mouse from Sun- 
com Technologies attaches to the side 
of a laptop computer to offer cursor 
control with optional speeds and three 
function buttons. 

The Icontroller is compatible with 
Microsoft and Mouse systems and can 
be used with the IBM PC, XT, AT, 
and PS/2 Series 25 and 30. 

The device comes with a carrying 
case, a 25-pin adapter, and the neces¬ 
sary software. It has a five-year war¬ 
ranty and costs $99.95. 
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The Suncom Icontroller lets users 
employ a mouse when space is at a 
premium. 
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1C Announcements 


Company, Model, Function Comments R.S. No. 


Analog Devices 
AD75019 

Crosspoint switch array 


Linear Technology 
LT1122 

Operational amplifier 


Micro Linear 
ML4817 
PWM controller 


Micro Linear 
ML4818 

Power supply controller 


Micro Networks 
MN6900.6901 
ADCs 


Motorola 
FDDI 
Chip set 


Motorola 
ECOxO series 
Embedded controllers 


Siemens 

SAB R3000A.R3010A 
Microprocessor, FPA 

Sipex 

SP2000 series 
Analog ASICs 


Texas Instruments 
SCOPE 
Logic device 


Xicor 

XM28C020 

EEPROM 


Customizable Linear System Macro from company ’ s BiMOS II cell library handles analog signals 120 

of up to 26 V peak-to-peak. The 256-switch device is twice the size of comparable 8x6 arrays and 
connects any of 16 analog inputs to 16 outputs. Control interface is a TTL/CMOS-compatible, three- 
wire serial port with internal latches to store switch setups. Each 44-pin PLCC device consumes 
2 mW quiescent current. Operation specified at±12V and+5V can occur from a single supply or 
asymmetrical bipolar sources .Cost(100s):$15. 

JFET device typically settles in 340 ns in 12-bit data-acquisition and conversion systems. Symmetri- 121 
cal slew rate of 80V/ps helps produce 0.001 -percent harmonic distortion. Internally compensated 
for unity gain stability with a bandwidth of 14 MHz and a power bandwidth (20V p-p) of 1.2 MHz. 

Features 600-p.V input offset voltage, 75-pA input bias current, and 40-pA input offset current. 

Comes in 8-pin SO surface mount, plastic, and hermetic DIPs. Cost (100s, PDIPs): from $2.50. 

Integrated pulse-width modulation IC for 1 -MHz single-ended switch mode power supply features 122 

accurate duty-cycle limits. Eliminates trimming, reduces external circuitry, and allows more use of 
power supply ’ s magnetic components. Fault-protection circuit resets after short circuit, shutting off 
power while providing constant current limit to ride out high load demands. A 1,5 V threshold limit 
comparator provides cycle-by-cycle current limit. Fabricated with a 40 V bipolar process using 
FB3480 vertical tile array. Cost (100s): $3.75. 

IC for soft switching control uses phase-modulation topology for workstations, minicomputers, 123 

mainframes, and high-end PCs. Combines switching attributes of resonant topology with square- 
wave PWM operations. Uses energy stored in parasitic inductance and capacitance to switch at 0V 
across the MOSFETs. Comes in molded 24-pin DIPs. Cost (100s): $8.20. 

Eight-bit flash MN6900 and 6901 convert input signals at 500 and 250 MHz. The MN6900 main- 124 
tains a 7.0 ENOB rate, the MN6901 6.8 ENOB. Contain on-board T/H amplifier for dynamic linear¬ 
ity while sampling signals with frequency components near Nyquist limits. Driven from 50£2 sourc¬ 
es and offer+1/2 LSB integral linearity. Come in 84-pin ceramic strip-line surface-mount packages 
with attached heat sinks. Evaluation boards available. Cost (100s): 6900, $990; 6901, $450. 

Four-chip set implements physical layer and media access control sublayer of ISO’s OSI model. The 125 
68836 FDDI clock generator performs clock and data recovery and NRZI. The 68837 elasticity and 
link manager supplies data framing, buffering, encoding, and decoding. The 68838 media access 
controller features fair and deterministic sharing of the physical medium, while the 68839 FDDI sys¬ 
tem interface connects protocol-specific chips to the user system. Cost (1,000s): $265. 

The 68EC000,68EC020, and 68EC040 microprocessors support embedded applications that re- 126 
quire low levels of functional integration or use proprietary circuits. The company streamlined the 
68000, -020, -030, and -040 to produce the 32-bit series. Cost: (10,000s, available third quarter) 

68EC000, from $2.95; 68EC020, from $15; (each, available fourth quarter) 68EC040, from $ 140. 

Mips Computer Systems-certified 33-MHz R3000A offers additional options over the previous ver- 127 
sion. A reversed “endianess” (LSB/MSB) bit enables dynamic choice of transmission. Nonmandato¬ 
ry use of parity bits for data and tag buses allows cache line reduction. Cost (1,000s): from $370. 

SP2101 and 2104 are to be used with a library of analog macrocell functions that include amplifiers, 128 
S/H amplifiers, comparators, multipliers, references, and logic cells. The SP2101 four-tile array 
contains 180 transistors and 26 I/O pads. The SP2104 12-tile array (3x4 matrix) has 484 transistors 
and 46 I/O pads. A databook summarizes features and includes schematics and specifications. 

System Controllability/Observability Partitioning Environment consists of octal registered trans- 129 
ceivers and 16- and 18-bit Widebus transceivers manufactured in TF s BiCMOS technology. De¬ 
vices incorporate a four-wire serial scan test bus conforming to JTAG specifications. In variety of 
packaging that reduces occupied board area. Sampling third quarter of 1991. 

CMOS 256 x 8,2 -Mbit EEPROM allows designers to select various depths of organization and lets 130 

current 1 -Mbit users upgrade system memory. Features 5 V latched operation and JEDEC software 
data protection. Portions of the array can be read concurrently while writing occurs to another por¬ 
tion. Cost (100s): commercial, each, $973.56; industrial, each, $1,168.27; military, $2,190.51. 
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INTERNATIONAL CONFERENCE ON 

Applications- Specific Array Processors 

(ASAP’91) 

September 2-4,1991 Costa Brava, Spain 

This conference is the 5th of the series which began with the International 
Workshop on Systolic Arrays held in Oxford, England in 1986. The expanded 
scope reflects the growing interest in applications-specific computing. Themes 
emphasized include algorithms, software, architectures, design methods and perfor¬ 
mance evaluation of applications-specific parallel computing systems. 


ADVANCE PROGRAM 
Monday, September 2 
Opening Session 

- Keynote Address: The Case for Application Specific 
Computing, E. Swartzlander, USA 

-Parallel Digital Implementation of Neural Networks, 
K. W. Przytula, USA 
Session 1: Special-Purpose Designs I 

- On the Use of Most Significant Bit First Arithmetic on 
the Design of High Performance DSP Chips, J. V. 
McCanny, N. Ireland 

- Implementation of a VLSI Polynormal Evaluator for 
Real-Time Applications, G. Corbaz et al, France 

-An Advanced Defect Tolerant Systolic Array Imple¬ 
mentation for Real-Time Image Processing, V. Hecht 
et al, Germany 

-The Systematic Design of Motion Estimation Array 
Architecture, J. Roseel et al, Belgium 
Session 2: Mapping Techniques 

- Transformation of Systolic Algorithms for Interleav¬ 
ing Partitions, A. Fernandez, J. M. Llaberia, Spain 

-Mapping Different Node Types of Dependence Graphs 
into the Same Processing Element, U. Vehlies, Ger¬ 
many 

-Mapping FIR Filtering on Systolic Rings, A. Varvit- 
siotis, S. Theodoridis, R. Melhem, Greece 
Session 3: DSP Architectures 

- The Missing Dimension in Real Time Signal Process¬ 
ing Architectures, J. Robinson, USA 

- Wave Digital Filter Three Port Adaptors with Fine 
Grain Pipelining, R. J. Singh, J. V. McCanny, N. Ire¬ 
land 

- The Arithmetic Cube: Error Analysis and Simulation, 
M. Vishwanath, R. M. Owens, M. J. Irwin, USA 

-Biological Information Signal Processor, E. Chow, T. 
Hunkapiller, J. Peterson, M. S. Waterman, USA 
Panel Session 

Tuesday, September 3 
Session 4: Multiprocessor Systems 
-Scalable System Interconnects for Shared-Memory 
Multiprocessors, K. Hwang, USA 

- Partitioning Schemes for Circuit Simulation on a Mul¬ 
tiprocessor Array, R. Telichevesky, P. Agrawal, J. A. 
Trotter, USA 

-Parallel Implementations of Discrete Relaxation 


-Parallel Strong Orientation on a Mesh-Connected 
Computer, M. Schimmler, Germany 



Session 5: Special-Purpose Designs II 
-Parallel Array Architectures for Motion Estimation, T. 
Meng, USA 

-CAPMA: A Content-Addressable Pattern Match Architec¬ 
ture for Production Systems, C. Dou, S-M. Wu, Taiwan 
-High Speed Implementation of 1-D and 2-D Morphological 
Operations, J. Vlontzos, USA 

-Pipelining and Transposing Heterogeneous Array Circuits, 
W. Luk, United Kingdom 
Session 6: Systems Design 

-Introduction to System Design: Algorithms and Parallel 
Architectures, E. Deprettere, Netherlands 
-A Decoupled Access!Execute Processor for Matrix Algo¬ 
rithms: Architecture and Programming, M. E. Figueroa, J. 
Moreno, Chile 

- Uniform but Non-Local DAGs: A Trade-off Between Pure 
Systolic and SIMD Solutions, T. Risset, Y. Robert, France 

-A TSP Engine for Performing TABU Search, V. Karam- 
cheti, M. Malek, USA 
Session 7: Synthesis and Verification 
-Synthesis of Systolic Arrays by Equation Transformation, P. 
Quinton et al, France 

-Automatic Formal Verification of Systolic Array Designs, N. 
Ling, F. Lin, T. Shih, R. Davis, USA 
-Consistency in Dataflow Graphs, E. A. Lee, USA 
Poster Session 

Wednesday, September 4 

Session 8: Systolic Array Design Methodologies 

-Synthesizing Systolic Arrays: Some Recent Developments, 
A. Darte, T. Risset, Y. Robert, France 
-A Design Method for On-line Reconfigurable Array Proces¬ 
sors, J. Franzen, Germany 

- Processor Clustering for the Design of Optimal Fixed-Size 
Systolic Arrays, J. Bu, E. Deprettere, Netherlands 

Session 9: Special-Purpose Architectures 
-The Design of a Highly-Pipelined 2nd Order IIR Filter 
Chip, O. C. McNally, J. V. McCanny, R. F. Woods, N. Ire¬ 
land 

-GFLOPS: A General Flexible Linearly Organized Struc¬ 
ture for Images, D. Houzet et al, France 
-Fast Generation of Long Sorted Runs for Sorting a Large 
File, Y-C. Lin, Y-H. Chang, Taiwan 
Session 10: Systolic Designs 

-A Modular Systolic 2-D Torus for the General Knapsack 
Problem, R. Andonov, F. Gruau, France 
-A Systolic Algorithm for Triangular Stein Equation, J. L. 
Hueso, G. Martinez, V. Hernandez, Spain 

- Systolic Architecture for Adaptive Eigenstructure Decompo¬ 
sition, S. Erlich, K. Yao, USA 


Registration 
Before Aug. 1 


Organiza 


IEEE Member Non-Member 
27500 Pta 36300 Pta 

(US $250.00) (US $330.00) 
36300 Pta 44000 Pta 

(US $330.00) (US $400.00) 


Address: _ 
City/State/ 
Cou 


Country: _ 


If paying in pesetas (Pta), mail check payable to 
"ASAP’91" to: Dr. Miguel Valero, Dept. 
d'Arquitectura de Computadors, Univ. Politecnica 
de Catalunya, c/. Sor Eulalia de Anzizu, Modul D 
4,08034 Barcelona, SPAIN. If in US Dollars, pay 
to "ASAP’91, Princeton" and mail to: Susan Gaf- 
gen. Dept, of Electrical Eng., Princeton Univ., 
B228, Engineering Quad, Princeton, NJ 08544- 
5263, USA. Fee covers proceedings, 3 meals, 
receptions, snacks, etc. Checks will not be cashed 
until Sept. 

On acceptance of paid registration, a preliminary 
hotel reservation will be made and an information 
packet, including instructions to confirm lodging, 
will be sent to registrant. 


CALL FOR POSTERS 
To allow for the inclusion of very recent 
results, ongoing projects and exploratory 
work, a session will be dedicated to their 
presentation in poster form. These will 
not be reviewed nor appear in the 
proceedings. Because space is limited, 
send poster titles by Aug. 15 to: Cathy 
Tanner, School of EE, Purdue Univ., W. 
Lafayette, IN 47907, fax: 317 - 494- 
6440, e-mail: cathy@ecn.purdue.edu. 




















Company, Model, Function 

Comments R.S. No. 

AIR Inc. 

AIR486ES, 486EL 
Motherboards 

Boards feature 25- or 33-MHz 486 processor with 8 Kbytes of internal cache RAM and Weitek 4167 135 
coprocessor. The regular-sized 486EL has 256 Kbytes of external cache RAM and 64 Mbytes of on¬ 
board memory. The smaller 486ES comes with 32 Mbytes of on-board memory. Each has two serial 
ports, one parallel port, and a mouse port. Cost (no CPU or RAM): 486ES, $ 1,900; 486EL, $2,200. 

Alcor Inc. 

DSP32C-4 

Multifunction board 

VMEbus module for Sun workstations contains four 50-MHz DSP32C chips that process data and 136 

digital signals at 100 Mflops. Includes a 12-bit, 10-MHz ADC; a 12-bit, 25-MHz DAC; a test signal 
generator; 16-bit external input and output ports; and four DSP serial ports. Three memory banks in 
each DSP offer 384 Kbytes of zero- or one-wait-state SRAM upgradable to 1.5 Mbytes. 

ATI Technologies 

VGA Wonder XL 
SuperVGA board 

Simultaneously displays 32,768 colors in 640 x 480 resolution using a blending technique to pro- 137 

duce 24-bit true images in 15-bit color. Supports 72-Hz refresh rates, 1-Mbyte memory, 256 colors 
inl,024x768 and 800 X 600 noninterlaced and interlaced resolutions. Mouse port and three-button 
mouse included. Cost (with Windows 3.0 drivers): from $299. 

Imperial Technology 
Megaram SCSI 
Solid-state disk 

Plug-and-play disk allows four hosts to simultaneously access data. RS-232 cable lets users partition 138 
data storage into differently sized logic units, priortize controllers, and access built-in diagnostics 
and self-test. Occupies 5.25-in. footprint and comes in 16- to 320-Mbyte versions with access time 
of 0.05 ms. Backup options protect data during power outages. Cost (per Mbyte): from $300. 

Micro Way 

Fast Cache-SX/Plus 

AT expansion card 

Full-length 16- or 20-MHz card converts IBM ATs into 386SXs with up to 8 Mbytes of extended 139 

memory. Supports Windows 3.0, Desqview-386, OS/2, and existing hardware. Delivers 1.7 Mega- 
Whetstone performance when run with optional 387SX. Memory is organized as 16 bits configu¬ 
rable as 0.5,1,1.5,2,4,6, and 8 Mbytes. Cost: from $595. 

Mitsubishi Electronics 
MF356C 

Diskdrive 

Floppy disk drive provides read-and-write interchangeability for conventional 1 - and 2-Mbyte and 140 

barium ferrite 4-Mbyte disks. Compatible with anticipated IBM PS/2s and existing Intel and Nat’l 
Semiconductor controller chips. Features automatically sensed and selected density mode, format¬ 
ted capacity of 2.8 Mbytes, and 1,000-Kbps transferrate. Available to OEMs and system integrators. 

Pacific Parallel 

Twin Tram 

Transputer module 

Credit-card-sized module features two Inmos transputers with up to 4 Mbytes of DRAM each. 141 

Comes with integer-only T400 processors or T805s with double-precision floating-point support. 

T805s run at 25 MIPS and 3 Mflops. Standard pinout allows simple configuration of parallel systems 
without using custom hardware. Cost (OEM, T805s): $850. 

R.C. Electronics 

RC-AAF 

Filter 

Antialiasing eight-pole filter for data-acquisition systems and digital storage oscilloscopes corrects 142 
A/D sampling errors. Comes in Elliptical, Butterworth, or Bessel configurations with 8 to 128 chan¬ 
nels . Users can program the PC bus or transmit external programming through two serial lines. Cost 
(per channel): from $500. 

Seaport Imaging 

VIP 

Image-processing board 

Scanner controller and image-processing board for Apple Macintosh IIs contains parallel RISC 143 

processors running at 50 MHz and provides 16 Mbytes of on-board RAM. Includes set of Think-C 
library routines to let integrators download code. Can process two images per second. 

Standard Microsystems 
DVB-20020 
Development kit 

Kit for the COM20020 intelligent controller for real-time networking includes a development board 144 
with prototype area that contains the controller, an 8751 8-bit microcontroller, and physical-layer 
interface-support circuitry. Assembly code drives the controllers, and C-language software supports 
communication between the DVB-20020 and PC-based nodes. 

3Com 

Etherlink 16 TP 

Ethernet adapter card 

Adapter card for twisted-pair Ethernet networks functions with 1 OBase-T wiring and prestandard 145 

hubs. Includes Netware and LAN Manager drives, diagnostic software, and LEDs. Features zero- 
wait-state, 64-Kbyte RAM buffer; shared-memory architecture; and two LEDs that display network 
status. A Multiconnect repeater enables operation with IBM Type 1 cabling and other wiring 
schemes that do not conform to the lOBase-T standard. Cost: $479. 
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IEEE COMPUTER SOCIETY 
Membership / Subscription Application 




BENEFITS 


Computer 

You automatically 
receive Computer with 
membership. Written, 
reviewed, and refereed 
by experts, it features 
survey and tutorial 
articles covering the 
entire computer field, 
and departments such 
as new products, pro¬ 
duct reviews, standards, 
and a reader forum 
called "The Open 
Channel." (monthly). 

Technical Committees 

Participate in one or more of our 33 technical 
committees — networks of professionals with common 
interests in specialty areas within computer hardware, 
software, and applications. 

Standards Working Groups 
Participate in the development of the more than 100 
standards projects currently sponsored by the society 
in such diverse areas as software engineering, local 
area networks, microprocessor buses, design automa¬ 
tion, programming languages, and standards 
definitions. 

Computer Society Press Books and Videos 

Receive discounts of up to 50°/o on over 700 titles 
covering a broad spectrum of computer science topics 
such as networking, communications, advanced 
systems, image processing, security, artificial 
intelligence, and visualization. Over 120 new products 
are published annually. 

Conferences and Tutorials 
Choose from more than 100 conferences annually, 
ranging from large industry-oriented conferences 
replete with exhibits to small, highly interactive 
workshops. Members receive special low rates. 


Schedule of Fees 


To join: see item 1, 2, or 3. 
To subscribe: see item 4. 


Membership dues and periodical subscriptions are annualized to, and expire on, 
December 31. Pay full- or half-year rate depending on date of receipt by the 
Computer Society as indicated below. Half Year Full Yfear 

Mar 1-Aug 31 Sept 1-Feb 28 


I don’t belong to the IEEE and I wan* 
to join just the Computer Society 


□ $27.00 □ $ 54.00 


) I don’t belong to the IEEE and I want 
■ to join both the Computer Society and the IEEE* 

I reside in Region 1-6 (United States). □ $52.50 □ $105 

I reside in Region 7 (Canada). □ $48.50 □ $ 97 

I reside in Region 8 (Europe, Africa, orthe Middle East) □$48,00 □ $ 96 

I reside in Region 9 (Latin America). □ $44.50 □ $ 89 

I reside in Region 10 (Asia and Pacific). □ $43.50 □ $ 87 

id the Computer Society may deduct $5 off the 


[ I already belong to the IEEE and I want 
to join the Computer Society 

IEEE Member Number 


□ $ 11.00 □$ 22 


I OPTIONAL PERIODICALS for new or current members 

' per year 

IEEE Computer Graphics and Applications .6 □ $12.00 

IEEE Design and Test . 

IEEE Expert . 

IEEE Micro . 

IEEE Software . 

Transactions on: 

Computers . 

Knowledge and Data Engineering 

Parallel and Distributed Systems . 

Pattern Analysis and Machine Intelligence 
Software Engineering . 


DC residents add sales tax to optional periodicals. 

□ Checks accepted in Belgian, British, German, Swiss, Japanese, or US currencies. 
Checks must be drawn on a bank in the country of origin of the currency. 


□ $12.00 
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□ $11.00 
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if elected, will be governed by IEEE’s and the society’s constitutions, bylaws, and statements of 
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ENDORSER (an IEEE member. Senior Member, or Fellow who knows you professionally) 
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Return to: IEEE Computer Society, 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264 USA. PC691 

Residents of Europe mail to: IEEE Computer Society, 13, Avenue de I’Aquilon, B-1200, Brussels, BELGIUM. 

Asian/Pacific residents mail to: IEEE Computer Society, Ooshima Building, 2-19-1 Minami-Aoyama, Minato-ku, Tokyo 107 JAPAN. 
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PRODUCT REVIEWS 


Editor: Richard Eckhouse, University of Massachusetts-Boston. Send review submissions to MOCO Inc., 770 Country Way, N. Scituate, MA 02066 
Compmail, r. eckhouse; Bitnet, eckhouse@cs. umbsky. 


Drawing and presentation graphics 

This month we review everything from object-oriented graphics to text en¬ 
hancers to Postscript laser printers. We hope this wide range of reviews makes 
interesting reading for those of you working on engineering drawings, desktop 
publishing, and graphics design. 


Object-oriented graphics 

Richard Eckhouse, University of Massachusetts-Boston 


Graphics Enhancer from Wang Labo¬ 
ratories was designed with the technical 
user in mind. It offers capabilities similar 
to those of a CAD tool along with the de¬ 
sirable features more typically found in 
paint programs. The result is an object- 
oriented graphics package that retails for 
only $295 and offers easy-to-use — yet 
sophisticated — free-form color graphic 
design running under Windows. 

The real significance of this object-ori¬ 
ented software is that its images can be 
easily modified. Thus (going beyond 
simple tasks), Graphics Enhancer lets the 
user modify the appearance of objects by 
rotating, distorting, skewing, filling, or 
applying a perspective to them. Because 
the program combines typical paint pro¬ 
gram objects with CAD features, you can 
easily produce sophisticated images. You 
can enter circles, ellipses, arcs, polygons, 
and text by clicking on the appropriate 
toolbox icons. CAD features include 
changing line styles and widths, zooming 
in or out, and grouping, duplicating, cen¬ 
tering, aligning, cutting, and pasting ob- 

Running under Windows, Graphics 
Enhancer offers such familiar features as 
title, menu, and scroll bars, along with 
lines showing status and statistics. It also 
offers “microhelp” (such as context-sen¬ 
sitive prompts on the current operation). 
Drop-down menus include operations 
grouped under the headings File, Edit, 
Draw, Modify, Settings, View, Selection, 
and Attributes. Each is explained in de¬ 
tail in a separate chapter of the user’s 
guide. A few special operations are 


(1) Get, for adding another drawing to 
your current drawing (in the File 
menu); 

(2) Bring to Front/Send to Back and 
Put in Front of/Put in Back of, for 
ordering objects (in the Edit 
menu); 

(3) Marker, for adding one of eight 
markers to a figure (in the Draw 
menu); 

(4) Align, Reshape, Rotate, Flip, Dis¬ 
tort, Skew, and Perspective, to 
change an object (in the Modify 
menu); 

(5) Page, Grid, Ruler, Snap, Con¬ 
straint, and Preference to affect 
how you maneuver within your 
workspace (in the Settings menu); 
and 

(6) Group, Ungroup, and Lock for 
placing objects either into one unit 
for manipulation or preventing un¬ 
intentional modification (in the 
Selection menu). 

The well-written user’s guide includes 
a table of contents, an index, and three 
chapters devoted to tutorial material. In¬ 
stallation requires the user to simply 
“run” the install program from within 
Windows. Because of the large number 
of files copied from the floppies (both 
5.25- and 3.5-inch), installation took 
about 10 minutes. Afterwards, execution 
was snappy on the 33-MHz 486 I used to 
run the software in both 800 x 600 and 
1,024 x 768 display modes. The pro¬ 


grams and artwork required nearly 6 
Mbytes of disk space. 

A library of over 300 pieces of clip 
art comes with the package. An impres¬ 
sive set of sample drawings demon¬ 
strates the power of this software. The 
only catch is that the drawings involve 
extensive use of color, which is obvi¬ 
ously lost when the file is sent to a 
black-and-white printer. However, im¬ 
ages are saved as computer graphics 
metafiles (CGMs) and can be imported 
by software that accepts that format. 
Otherwise you can cut and paste through 
the clipboard. 

I haven’t seen much more than a men¬ 
tion of Graphics Enhancer in the trade 
press; it may be the sleeper of the year. 
Even though Merisel distributes the 
package, I have yet to see any mail-or¬ 
der house offering it in an ad. That’s a 
real shame, since this graphics software 
is a powerful drawing package in a vari¬ 
ety of applications and is not limited to 
word processing or desktop publishing 
as so many other competing products 

This is a valuable piece of software. It 
clearly replaces the familiar paint pro¬ 
gram with a much more comprehensive 
package, yet it offers the precision of a 
CAD package without all the details. 

I heartily recommend it. 

Readers can contact Wang Laborato¬ 
ries Inc. at One Industrial Ave., Lowell, 
MA 01851; (508) 459-5000. 
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A revolution in resolution 

Richard Eckhou.se, University of Massachusetts-Boston 


The proliferation of scanners in the 
workplace mandates a raster-to-vector 
conversion program. Envision It from 
Envisions Solutions Technology is just 
such a program and quite a bit more. The 
package provides four essential ingredi- 


• raster-to-vector conversion, 

• a graphics editor, 

• conversion utilities, and 

• printing and plotting functions. 

The program can read the TIFF and 
PCX files produced by most scanners 
and paint programs, as well as DXF, 
ASCII (both text and x-y coordinate 
pairs), and HPGL files. In addition, it 
can write DXF, GEM, EPS, HPGL, and 
PCX files. The files it reads are convert¬ 
ed to an internal Envision It format as 
vectors that can then be manipulated 
with a graphics editor. Users can affect 
the conversion process by setting a num¬ 
ber of parameters related to shape recog¬ 
nition. 

The graphics editor screen looks like a 
cross between something from Windows 
and a CAD program. Across the top you 
have eight command menus labeled 
Files, Edit, Arc/Circ, Lines, Blocks, Pa¬ 
rameter, Points, and View. Clicking on a 
command produces a subcommand, but 
many of the subcommands also appear in 
the two icon menus along either side of 
the center drawing area. That area is en¬ 
closed by a grid on all four sides. A sta¬ 
tus line across the bottom gives the num¬ 
ber of points on the drawing that were 
selected, the current layer, the zoom fac¬ 
tor, and the x-y coordinates. Below that 
line is a prompt line for command entry 
or completion. In the Super VGA resolu¬ 
tion (800 x 600) that I used, this repre¬ 
sents a considerable amount of informa¬ 
tion. 

Because the designers of this software 
have recognized that not everyone likes 
icons or mice, they have allowed key¬ 
board entry for all commands and cursor 
positioning. In fact, all commands can be 
entered in their short form or with one 
keystroke — a thoughtful touch. 

Often the first step in using Envision 
It is to convert a bit-mapped image to a 
vector format. The next step is to use the 
graphics editor to fix things up. The edi¬ 
tor offers a number of commands — 
such as bend, block, curve, join, layer, 
orthogonal straighten, point move, show 
points, smooth, stretch, text, and zoom 
— for that purpose. These commands 
represent but a small fraction of the set 
offered, and each is as powerful as you’d 



A partial PC-board schematic converted by Envision It from a TIFF file to an 
HPGL vector format. 


find in a CAD package. I did miss some 
of the snaps — endpoint, intersection, 
etc. — common to the CAD package I 
normally use. However, the line snap, 
gravity point, and midpoint commands 
combined with a snap-to-grid made it 
very easy to accomplish the same kinds 
of things in a slightly different manner. 

Installing Envision It means running 
the install program that comes on the 
three 5.25-inch or two 3.5-inch floppies 
and using the setup program to specify 
the units of measure and the display 
adapter, printer, plotter, and pointing de¬ 
vice. System requirements are rather 
modest: a 512-Kbyte PC, a graphics dis¬ 
play adapter, and a hard disk. A mouse, 
digitizer, and coprocessor are optional, 
and output can be sent to a large variety 
of dot matrix or laser printers and plot¬ 
ters. Interestingly, Postscript printers are 
not directly supported except through the 
EPS file format. 

The indexed manual that comes with 
the software is nothing special. The sec¬ 
tion on raster-to-vector conversion sim¬ 
ply states the facts, the tutorial is not par¬ 
ticularly helpful, and the editor 
commands are not referenced to the com¬ 
mand menus that contain them. Howev¬ 
er, everything you really need is there, 
including examples of how some of the 
commands work, the types of hatch pat¬ 


terns available, and examples of the 20 
different text fonts. A reference guide 
lists every command in alphabetic order 
along with the short and keystroke form, 
and a one-line description. 

Because this package includes a num¬ 
ber of different capabilities, switching 
from the graphics editor to the scan menu 
takes you from graphics to text mode. 
This makes sense because there is no rea¬ 
son to stay in graphics mode, but it sur¬ 
prised me at first. However, you can use 
either the keyboard or a pointing device 
to select menu items in either mode, 
which provides a certain consistency. 

At $399, this software is reasonably 
priced, given that four utilities are bun¬ 
dled into one package. It is easy to use 
and offers functionality often found in 
much more costly products. Instead of 
digitizing engineering drawings, you can 
scan them in and clean them up in short 
order. The savings in time well justifies 
the price. Until the end of June (if sup¬ 
plies last), the company will ship a free 
Scan Man Plus hand-held scanner with 
each product. 

Readers can contact Envisions Solu¬ 
tions Technology Inc. at 822 Mahler Rd., 
Burlingame, CA 94010; (415) 692-9061; 
fax (415) 692-9064. 
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Making the right equation 

Richard Eckhouse, University of Massachusetts-Boston 
Sorel Reisman, California State University, Fullerton 


We discovered Math Type indepen¬ 
dently and immediately decided we bad¬ 
ly needed this tool. As converts to the 
graphical style word processors, we were 
at a loss as to how to place mathematical 
equations “easily” into our technical pa¬ 
pers. By easily, we mean a WYSIWYG 
equation editor, since we use both Word 
for Windows and Ami Professional. Be¬ 
cause we are not Macintosh users, we 
were unaware that Design Science had 
been shipping Math Type for that ma¬ 
chine since 1987. But, having learned the 
product’s pedigree, we were not sur¬ 
prised to find how well suited it is to the 
Windows environment. 

We could describe Math Type as a ba¬ 
sic point-and-click utility — but that is 
much too simple. This product offers 
templates consisting of symbols and 
empty slots. When you need a symbol, 
such as an integral, summation, fraction, 
or subscript, you click on its icon and it 
appears in the workspace. Then you tab 
between slots, filling in the missing in¬ 
formation. The last step is to cut and 
paste the result into your document. This 
step is automated in both Win Word and 
Ami Pro through the use of Windows’ 
DDE (Dynamic Data Exchange) and a 
set of macros. These macros add a new 
equation, paste the results into your doc¬ 
ument, bring an equation back into Math 
Type for editing, and replace the original 
equation, all through the use of the clip¬ 
board. 

To be really useful, a system like this 
needs lots of symbols and templates. 

Math Type provides 158 symbols and 
119 templates. To avoid cluttering a user 
window. Math Type arranges the screen 
into “pop-ups” and “strips.” A separate 
pop-up for symbols or templates holds 
the complete palette. The symbol and 
template strips hold the most frequently 
used set of symbols or templates. You 
can customize each strip through editing. 


The macro strip can store up to 32 
commonly used expressions that have 
been filled in (like the summation from 
i = 1 to n). Very thoughtfully, the design¬ 
ers let users enable or disable the display 
of pop-ups and strips. 

Other built-in conveniences let you 
“nudge” symbols if you don’t care for 
the spacing and positioning of characters 
using standard mathematical typesetting 
rules. Alignment is handled intelligently, 
but users can force it so that equations 
are aligned left, right, center, on an 
equality/inequality sign or decimal point, 
as well as at the top, bottom, or center 
for piles and matrices. You can set the 
formatting algorithms, which include line 
spacing, matrix row/column spacing, 
superscript height, subscript depth, and 
limit height. While you can set these 
units in inches, centimeters, millimeters, 
points, or picas, an even better option 
lets you use a percent of your full type 
size. That way the settings remain pro¬ 
portional when you change type sizes. 

Typefaces are determined in another 
menu and can be set to any of those avail¬ 
able within Windows for 10 different cat¬ 
egories: text, function, variable, lowercase 
Greek, uppercase Greek, symbol, vector, 
number, and two user-defined styles, all 
in normal, bold, or italic styles. 

Why so many typefaces? Math Type 
can recognize special words like “sin” or 
“lim” so that it can set them in the appro¬ 
priate typeface. You can override this, but 
most of the time it is neat to see Math 
Type at work. And since you may have a 
laser printer without the necessary built-in 
typefaces. Math Type provides the neces¬ 
sary font files that are dynamically loaded 
when you print your document. 

A number of other features merit spe¬ 
cial mention. These include 

• saving equations as Windows meta¬ 
files, encapsulated Postscript, or 


Aldus Placeable metafiles; 

• two-way translation to Tex; 

• compatibility with the Mac version; 

• expanding round, square, curly, and 
angle brackets; 

• single and double bars for determi¬ 
nants and norms; 

• limit templates for lim, limsup, min, 
max, etc.; 

• overbars for complex conjugates and 
set closures; 

• unions and intersection of sequences 
of sets; and 

• matrices and tables with solid, 
dashed, and dotted lines. 

We did find a number of limitations in 
the current 1.0 version of the product, all 
of which should be corrected by the time 
you read this review. These include lack 
of (1) Super VGA and 8514 video mode 
support, (2) support for dot matrix print¬ 
ers, (3) Type 1 PS fonts or Adobe Type 
Manager support, and (4) a Windows- 
based installation procedure. Improved 
performance and a better help system are 
also promised, but we don’t consider 
these inadequate in the current release. 

The package retails for $249 and 
comes with an excellent manual that in¬ 
cludes a tutorial and multiple text files 
containing the latest information on us¬ 
ing this software with a large number of 
popular Windows graphical programs. 
Math Type requires a PC with at least 
640 Kbytes; a hard disk (with 1.5 Mbytes 
of free space) with VGA, EGA, or Her¬ 
cules graphics; a mouse; and either an 
HP Laser Jet- or Postscript-compatible 
printer (a free demo disk is available). 

We highly recommend this product. 

Readers can contact Design Science 
Inc. at 6475-B E. Pacific Coast Hwy., 

Ste. 392, Long Beach, CA 90803; (213) 
433-0685; fax (213) 433-6969. 
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A printer with a mind of its own 

Richard Eckhouse, University of Massachusetts-Boston 


For me, significant events in personal 
computing often relate to my acquisition 
of computer equipment that had previ¬ 
ously been just out of reach — usually 
because I couldn’t justify the expense. 
When I went to work for myself, the 


need for a PC became immediate; I fond¬ 
ly recall the purchase of my first IBM PC 
compatible. As loyal readers will remem¬ 
ber, the next significant event was 
marked by my acquiring a 386 machine 
(after acquiring several other PCs). The 


latest acquisition that pleases me im¬ 
mensely is my first Postscript laser print¬ 
er (not my first laser printer). 

The QMS-PS 410 printer is really 
worth the wait. It is compact, versatile, 
and very reasonably priced. It makes 
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The QMS-PS 410. 


printing easy and has changed the way I 
produce my business letters and reports, 
signs and labels, and special forms. Cou¬ 
pled with my GUI software, it has turned 
me into a producer of very professional¬ 
looking printed output. 

Since this isn’t my first laser printer, 
why has it changed the way I use a PC? 
The answer is that widespread software 
support means that I don’t have to think 
about loading the right typefaces and 
fonts. Whatever I want is there — that’s 
what having a Postscript printer is all 
about. With 45 resident typefaces from 
13 families that can be scaled from 4 
points upward and rotated to any degree, 
the 410 offers virtually unlimited possi¬ 
bilities. 

The 410 is based on a Motorola 68020 
running at 16.67 MHz and includes 2 
Mbytes of memory (upgradable to 6 
Mbytes). The Canon LBP-X print en¬ 
gine, familiar to users of both the LBP-4 
and HP-IIP (as is the form factor for the 
printer), produces 4 pages per minute. 
But, unlike these other printers, there is 
no LCD status panel and corresponding 
set of push buttons. Instead there are 10 
status lights, two push buttons labeled 
“Online” and “Test/Cancel,” and two 
slots for holding fonts and emulation car¬ 
tridges. This surprised me until I remem¬ 
bered that a Postscript engine is pro¬ 
grammable and you use PS statements to 
make the printer function. Although the 
manuals do cover PS programming, 

QMS has made things much simpler by 
supplying a utility called PSEXEC that 
establishes communication parameters, 
printer options, special features, and 
prints both PS and non-PS files. You can 
make some of the PSEXEC features resi¬ 
dent and call them up whenever you need 
to change something about the printer. 

QMS attributes this facility to the 
debut of its ASAP III (Advanced System 
Architecture for Postscript) controller 
technology. I would like all my printers 
to operate this way — without my need¬ 
ing a manual and a PhD to be informed 
enough to set up printer characteristics. 
But the features don’t stop there. The 
410 has ESP (an Emulation Sensing Pro¬ 
cessor) to recognize and switch between 
Postscript, HP PCL, or HP-GL (optional) 
printer languages. Combined with three 
printer ports, ESP allows me to simulta¬ 
neously connect the printer to three ma¬ 
chines using its parallel, serial, and Ap¬ 
ple Talk ports; the 410 automatically 
switches between them. It’s like having 
three printers in one cabinet. 

In testing the 410,1 was repeatedly 
surprised. First, I thought that 4 pages 
per minute would be noticeably slower 
than the 10-ppm laser I had been using. 

It wasn’t. Text-based output files are 
shorter and print faster. Also, the printer 


doesn’t need to download fonts like I 
used to for special typefaces. 

Second, I wasn’t sure how I would like 
a machine with only a 50-page upper 
feeder. The feeder turned out to be a 
blessing when I wanted to insert letter¬ 
head stationery, labels, or envelopes. 
Also, the ease in switching from face-up 
to face-down output helps ensure that en¬ 
velopes and labels don’t become too 
wrinkled in the process. But I did find 
the face-up output tray a nuisance be¬ 
cause it obscures the input tray. Also, af¬ 
ter testing the optional 250-sheet feeder 
that attaches to the bottom of the printer, 

I recommend against purchasing this 
$195 option unless you need the capaci¬ 
ty; the regular tray feed is that good. 

Third, although I thought 2 Mbytes 
would be enough memory, I ran into a 
problem printing a sample page from my 
CAD program. The machine would get 
about halfway through and then just stop. 
While the PSEXEC utility can load an 
error handler, that approach didn’t work 
— nor did any of my numerous calls to 
customer support. Although they were 
always friendly and promptly returned 
calls, sending them the offending file has 
yet to result in any suggested solution. 
Fortunately, a colleague told me that he 
suspected a stack-overflow problem. The 
addition of another Mbyte confirmed his 
suspicion. 

Fourth, a Postscript printer allows lots 
more disk space because I no longer keep 
bitmapped fonts around for occasional 

Fifth, the HP emulation is the best I’ve 
seen on a non-HP laser. I use a number 
of utilities that assume a true HP printer 
and are demanding enough to demon¬ 
strate emulation quality. In the case of 
the 410,1 have yet to find any flaws. 

And, since switching between PS and HP 
emulation is automatic, I don’t think 
twice about what I throw at the 410, 


leaving it up to the printer to sort every¬ 
thing out. 

Knowing what goes on in this machine 
is simply a matter of looking at just 
three of the indicator lights: active, re¬ 
ceiving, and paper out. The others — 
power, ready, online, printer error, paper 
jam, standard tray, and optional tray — 
are generally uninteresting. But if I do 
want to know more, I can ask the printer 
to generate a number of status sheets de¬ 
scribing everything from printer identifi¬ 
cation to memory allocation to data com¬ 
munications. Would you expect anything 
less from a printer with such a capable 
microprocessor? 

In keeping with the thoroughness of 
the printer design, the company has gone 
out of its way to provide the best manual 
set I’ve ever seen. The five manuals cov¬ 
er getting started, the user guide, applica¬ 
tion notes, the PS Executive, and ques¬ 
tions/answers. Each is very clearly 
written and illustrated, and includes ap¬ 
propriate tables of contents and indexes. 
The set covers use of the 410 with both a 
Mac and a PC, along with technical de¬ 
tails about Postscript and more informa¬ 
tion on HP emulation than I ever expect 
to need. 

At a suggested retail price of $2,795, 
this is the Postscript printer to buy. It of¬ 
fers simplicity, speed, expandability, and 
reliability. The only reason to look else¬ 
where is for more pages per minute. 

With QMS now incorporating ESP in its 
full line, the faster versions available 
from QMS would be the ones to consid¬ 
er. But, for me, the QMS-PS 410 has be¬ 
come my workhorse and number one 
printer. I would be lost without it! 

Readers can contact QMS Inc. at One 
Magnum Pass, PO Box 81250, Mobile, 
AL 36689-1250; (205) 633-4300; fax 
(205) 633-0013. 
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Tex typesetting with a difference 

T.L. (Frank) Pappas, Aweb Software Technology 


Donald Knuth’s Tex typesetting sys¬ 
tem is (without exaggeration) the most 
powerful and versatile software of its 
kind. Anyone who has used Tex (pro¬ 
nounced “teck” and frequently typeset as 
“T e X”) extensively knows this is true. 
They also know that using Tex can be 
difficult for anyone who doesn’t have the 
time or aptitude to learn the advanced 
features of Tex and its complementary 
programs. 

Since Tex is a “mark-up” language, 
documents are normally prepared using a 
text editor rather than a WYSIWYG edi¬ 
tor. When Tex formats a document, it 
produces a dvi (device-independent) 
file, not a printed document. Viewing or 
printing a formatted Tex document re¬ 
quires a separate program, called a driv¬ 
er, to process the dvi file. A driver that 
previews a document at a terminal is 
called a previewer. 

Vector Tex — or Vtex, as it’s usually 
called — from Micro Press sells for 
$299. Tex uses a standard set of macros 
called plain Tex. As with all implementa¬ 
tions, Vtex provides these macros. Most 
implementations charge extra for drivers, 
but Vtex comes with a previewer and 
several printer drivers. 

The previewer, which supports CGA, 
EGA, HGC, and VGA modes, has most 
of the features needed for viewing for¬ 
matted documents. The one missing fea¬ 
ture is a way to alter the magnification of 
a single page or the entire document as it 
is viewed, although the user can specify 
a magnification when starting the pre¬ 
viewer. 

Vtex comes with drivers for Postscript, 
HP Laser Jet-compatible, and dot matrix 
printers. The dot matrix driver supports 
common Epson printers, as well as the 
IBM Proprinter, the NEC Pinwriter, Star 
printers, and a few others. If you have a 
dot matrix printer not supported by Vtex, 
you can add support with a program sup¬ 
plied by Micro Press. 

Two features should be added to the 
laser printer drivers. One is an option for 
printing from last page to first to accom¬ 
modate printers that deliver pages face 
up. The other option is for printing only 
odd- or even-numbered pages for double¬ 
sided printing. 

All drivers can handle and scale .PCX 
and .MCP files produced by PC Paint¬ 
brush and MacPaint, respectively. In 
fact, Vtex makes this much easier than 
many other Tex implementations do. Tex 
users who have included graphics images 
in their documents will appreciate how 
easy this is to do with Vtex. The follow¬ 
ing command, used to include the White 


House image in the Vtex samples figure, 
is simply placed where the image is to 
appear and does not require allocating 
space for the image or knowing its size: 

\makepicbox {200} {200} % 

{whouse.mcp} 

Here \makepicbox is a macro provided 
by Vtex in a sample file. In the macro 
call, 200 means scale the image to 200 
dpi along both dimensions. The actual 
graphics size of the image in 
whouse.mcp is calculated by Vtex. Al¬ 
though not shown here, the size is avail¬ 
able through a predefined macro \size- 
graph, which takes a graphics file as an 
argument and sets the global variables 
\graphx and \graphy to the dimensions of 
the image in pixels. Placing figures using 
\makepicbox is considerably easier than 
in most Tex implementations, but the ap¬ 
proach isn’t portable. 

The Postscript driver can also handle 
EPS images. However, the previewer can 
only display .MCP and .PCX images. 

Vtex differs from other Tex implemen¬ 
tations primarily in its use of scalable 
vector fonts rather than raster fonts. A 
typical Tex implementation comes with 
an assortment of Tex-specific raster fonts 
called Computer Modern. 

Along with Vtex’s scalable fonts, I in¬ 
stalled three supplementary packages. 

The total installation required 2 Mbytes 
of storage, but it gave me more than 50 
distinct fonts. Moreover, you can scale a 
Vtex font to any size between 5 and 70 
points, slant it to any angle, compress or 
expand it from 40 to 200 percent, form 
outline and small caps, or shade it in 10 
different patterns. Each of these transfor¬ 
mations can be applied alone or in any 
combination, without using any more 
disk storage. 

Scalable fonts provide much greater 
variety and flexibility than Computer 
Modern raster fonts, and they require 
much less disk space. 

You do give up a few things if you 
choose Vtex. Since each Computer Mod¬ 
em font is designed individually, they 
will produce better results. However, this 
would be true for any raster font pro¬ 
duced by the Metafont Tex font-genera¬ 
tion program for a particular design 
when compared with any vector font 
scaled to the same size. Not all aspects of 
a font scale equally well. But this is no 
more of a problem than it is with Post¬ 
script fonts. On the other hand. Metafont 
is extremely difficult to use, so people 
don’t normally create new fonts with it. 
Micro Press has created “a visual ana¬ 


log” of Metafont called Instafont, with 
which they create their own fonts. The 
company plans to release Instafont soon. 

Micro Press also offers the Latex macro 
package (version 2.09) for $50.1 found 
two minor problems with it. First, the 
macro packages don’t seem to be the lat¬ 
est. Also, as distributed, the italic fonts 
need slant adjustment. Without these ad¬ 
justments, which are easy to make, Latex 
documents won’t produce the same re¬ 
sults as a conventional Tex system. 

Vtex comes stocked with a collection 
of fonts that lets you generate all of 
Computer Modern, with the exception of 
a few illustrative fonts such as Funny 
Roman and Funny Italic. Some standard 
Postscript-like fonts. Calligraphy fonts, 
and others are also available. You can 
buy these individually or in sets. By the 
time you see this review, Micro Press 
will offer a font set consisting of the 
standard Postscript-like fonts for $100. 
Currently, there is no way to use the resi¬ 
dent fonts on a Postscript printer, but 
Vtex is working on that. Of course, you 
can’t use the transformations available 
on Vtex fonts on the resident fonts. 

Micro Press also offers a $100 pro¬ 
gram called Pxlgen, which converts a 
Vtex vector font at a given size to a ras¬ 
ter font understood by other Tex imple¬ 
mentations. This means Vtex users can 
use whatever fonts they want in their 
documents and provide the necessary 
raster fonts to Tex users who are using 
conventional Tex. Moreover, conven¬ 
tional Tex users can purchase Pxlgen and 
other font sets to produce raster fonts for 
their own use. Since Pxlgen comes with 
the same standard fonts as Vtex, you get 
quite a lot for $100. 

One other aspect of Vtex is its connec¬ 
tion with Word Perfect. For $99, Micro 
Press offers the New Fase program to 
generate fonts for Word Perfect. It comes 
with the same collection of vector fonts 
found in Vtex. 

Word Perfect users, or anyone wanting 
a WYSIWYG front end to Tex or Latex, 
should get a program named Publishing 
Companion from K-Talk Communica¬ 
tions. For $249, you can write Word Per¬ 
fect documents and then generate Tex or 
Latex files. This is especially worthwhile 
for Tex users who either have typists ex¬ 
perienced in Word Perfect or would like 
to have their typists learn Word Perfect. 
For $129 K-Talk also offers Math Edit, a 
WYSIWYG math equation editor for 
Tex. The company can be reached at 
(614) 294-3535. 

I really like Vtex and I’m considering 
using it as my Tex system. The added 


92 


COMPUTER 








versatility makes all the difference. I 
would like to see other Tex vendors sup¬ 
port virtual fonts. 

Finally, Vtex is compatible with the lat¬ 
est 3.0 version of Tex. It comes with 
some documentation that explains how to 


use Tex, but the most complete source is 
still Donald Knuth’s The Texbook, pub¬ 
lished by Addison-Wesley. Make sure 
your edition is printed after October 1990 
so that it reflects the latest 3.0 changes. 
Anyone with an older version of The 


Texbook should probably upgrade. 

Readers can contact Micro Press Inc. 
at 6830 Harrow St., Forest Hills, NY 
11375; (718) 575-8038. 
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Serious design tools 

Sorel Reisman, California State University, Fullerton 


If you are a serious design artist or 
someone whose income depends on pro¬ 
ducing elegant and extravagant comput¬ 
er-based art, then Corel Draw or Micro- 
grafix Designer will interest you. Having 
spent many hours with these packages, I 
am convinced that they demand full-time 
involvement in exchange for their bene¬ 
fits. 

The products are similar, with overlap¬ 
ping strengths and weaknesses. Of 
course, each has some unique features. 
Both packages work under Windows 3.0, 
and, depending on the functions or 
amount of clip art you install, both re¬ 
quire an extraordinary amount of disk 
space — more than 7 or 8 Mbytes, re¬ 
spectively. Installation of both packages 
is relatively straightforward, and, consid¬ 
ering the disk requirements, unsurpris¬ 
ingly time-consuming. 

Learning the packages is not so 
straightforward. Corel Draw 2.0 contains 
a manual and a videotape tutorial that il¬ 
lustrates “basic” features. Learning De¬ 
signer 3.0 is a little more difficult be¬ 
cause only a hard-copy tutorial is 
provided. A separate training video is 
available for $16 (free if you send in the 
registration card). 

Starting to learn Corel Draw can be a 
little intimidating because there are eight 
manuals and brochures, as well as other 
miscellaneous material. There is so much 
“stuff’ in the Corel package that the 
company now sells a CD-ROM release 
of the product. Designer, on the other 
hand, seems less frightening because it 
contains only three manuals. 

Both packages present the user with 
Windows-style menus, and although De¬ 
signer’s interface seems more intuitive, 
neither interface substantially conforms 
to those found in most Windows soft¬ 
ware. Both products provide a wealth of 
functions beyond the visible menu op¬ 
tions, requiring you to learn and remem¬ 
ber arcane key combinations for very 
powerful drawing functions. Both pack¬ 
ages include extensive fold-out quick 
reference cards and provide a road map 
for execution of idiosyncratic key com¬ 
mands. Designer’s somewhat more intui¬ 
tive screen menu structure and its con¬ 


text-sensitive help make it a lot easier to 
use. In fact, Corel Draw needs all its 
manuals because there is virtually no 
available on-line help. 

The packages display quite different 
visual interfaces. Each displays its draw¬ 
ing tool menu down the left side of the 
screen. Designer allows you to remove it 
if you wish. Corel displays a removable 
color palette across the bottom of the 
window. Designer provides 10 visible 
horizontal pull-down options across the 
top of the window; Corel provides only 
six, allowing you to access additional 
functions via pull-out menus that reveal 
themselves when you select one of the 
drawing tools. Both packages provide 
more or less the same kind of file/edit/ 
drawing/etc. functions, but in a some¬ 
what different manner. I preferred the 
Designer interface because it resembles 
the paint program interfaces I’m familiar 
with. 

Despite the differences in packaging 
and user interface, these products deliver 
somewhat equivalent functions. You cre¬ 
ate graphical objects and grab, move, 
stretch, fill, hatch, color, cut, copy, and 
paste them within a drawing window. 
And, of course, you can display that win¬ 
dow differently in each package. For ex¬ 
ample, both provide print previews; 

Corel Draw provides a full-page preview 
or lets you preview sections of a drawing 
for reasons of performance. Designer lets 
you see a “microscopic” view of all pag¬ 
es of all your drawings. Neither set of 
options is superior, just different. 

Probably one of the most interesting 
features — and one where Corel Draw 
has Designer beat hands down — is 
Corel’s Effects menu. By using just your 
mouse, you can select objects and uni¬ 
formly distort and stretch them to pro¬ 
duce fantastic visual effects on relatively 
mundane text or graphic objects. Design¬ 
er has nothing to compare with this fea- 

Although both packages are intended 
mainly for drawing, they also contain 
very sophisticated text features. Corel 
provides a typeface library of more than 
150 typefaces and styles. The Designer 
list appears shorter, but most of the fonts 


can be bolded, underlined, etc., making 
the packages somewhat equal in terms of 
available fonts. However, Corel also pro¬ 
vides a stand-alone utility called WFN- 
BOSS that lets you create and edit your 
own fonts and symbols, which you can 
convert to Adobe Type-1 format. 

Both products let you see an example 
of your selected font. Despite the simi¬ 
larities in font availability, Designer pro¬ 
vides WYSIWYG text placement and 
manipulation, while Corel Draw requires 
that large blocks of text be prepared in 
an off-the-drawing window and then 
placed into the drawing. Because on- 
drawing editing of characters can be 
done at almost a bitmapped level, serious 
artists may consider this an advantage. 

A word of caution regarding Corel 
Draw’s fonts: In some cases, printed 
characters tend to contain small out¬ 
growths of dots. Corel is aware of this 
problem and is supposed to be providing 
a fix. 

Designer ships with over 1,000 sym¬ 
bols that represent “a sampling” of 25 li¬ 
braries available for purchase. On the 
other hand, Corel Draw contains a pow¬ 
erful stand-alone visual file manager 
called Mosaic that lets you examine 750 
iconic representations of compressed im¬ 
age files that can easily be imported into 
your work. Both packages contain hard¬ 
copy guides to help you select useful clip 
art. Corel Draw also contains a symbol 
library of more than 3,000 black-and- 
white symbols that can easily be access¬ 
ed, selected, and pasted into your work 
by simply pressing the mouse button and 
the shift key while in text mode. 

Both products provide a variety of im¬ 
port/export graphic file format filters. 
Designer can import and/or export CGM, 
DRW, DXF, GEM, GRF, PCT, PCX, 
PIC, TIFF, TXT, EPS, HP, and WMF 
files. Corel Draw can work with PCX, 
TIFF, BMP, DXF, EPS, GEM, PIC, PIF, 
PICT, WFN, WMF, AI, WPG, HPGL, 
SCODL, and CGM formats. However, 
neither package can import and export 
all listed formats. I recommend that you 
verify the specific import and export for¬ 
mats available for each package. 

(Note: If you are interested in working 
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in formats other than these, and the pack¬ 
age of your choice does not support the 
import/export formats of your environ¬ 
ment, I suggest that you examine IMSI’s 
Graphics Transformer. I used this prod¬ 
uct to manipulate and rework a received 
fax file that was stored to my hard drive 
using Frecom’s fax board proprietary file 
format. The Graphics Transformer is a 
very handy tool that can bridge paint or 
draw programs like Corel Draw or De¬ 
signer and just about any other graphics 
application.) 

Finally, in addition to the comparable 
primary functions and ancillary materials 
provided in the packages, Designer in¬ 
cludes two functions that give it unique 
added value. The first is Telegrafix (I did 
not test it), a stand-alone product for cre¬ 
ating SCODL files and transmitting them 
via phone line to an image-production 
center that produces 35-mm slides or 
overhead transparencies. The second 
function is a slide shower that lets you 
easily present image files using a variety 
of interesting wipes, fades, and special 
image-to-image transition effects. You 


Review note 


Qedit Advanced 2.1 — the 
“quick editor.” Qedit has success¬ 
fully insulated me from Edlin, the 
built-in DOS editor! That alone 
makes it very valuable. However, 
Qedit is good for more than just edit¬ 
ing your AUTOEXEC.BAT file. An 
amazing number of features occupy 
only 46 Kbytes of memory. 

You need just one file to run Qedit 
(Q.EXE). It is fast -— whether it’s 
scrolling, starting, saving, or exiting. 
It is easy to use; I never saw a manu¬ 
al for this program until I started this 
review (and I have used the package 
for several years). And it is extreme¬ 
ly configurable. In less than an hour 
I created a version that emulated al¬ 
most 30 of the most common Emacs 
commands, building an executable 
that an Emacs hacker could use with 
little or no learning curve. 

The default interface is so simple 
that all you have to do is start it up, 
specify a file name, and type. Hitting 
the escape key takes you to the main 
menu, and from there most functions 


can spend hours experimenting with 
these. 

I tested both products on a 20-MHz 
AST Research 386/C with a Super VGA 
display. Because both packages manipu¬ 
late objects (rather than pixels), they re¬ 
draw the object quite a bit when you 
make a change. For some reason, this 
seemed more noticeable with Designer. 
This process can slow you down if you 
want to get on with another function, but 
both packages let you interrupt whatever 
is going on so that you can select the 
next function. Although it was just ship¬ 
ping when I reviewed these products. 
Designer 3.1 allegedly addresses some 
performance issues, perhaps including 
this one. Because I was curious about the 
effect of using an 80387 on these draw¬ 
ing products, I tested Corel Draw with 
and without one. There did not seem to 
be any noticeable performance gain after 
the coprocessor was installed. 

Which product do I recommend? It re¬ 
ally comes down to a matter of personal 
preference. Except for Draw’s incredible 
special effects, I suppose that a profes¬ 


are easy to find. At this level, you 
can edit any text file and make si mple chang¬ 
es in seconds. 

Qedit also includes emulations of Word 
Star, Brief, Word Perfect, Norton Editor, 
and the IBM Personal Editor II. Screen 
colors, printer options, and tab settings 
are all configurable. My simple emacs 
clone used a copy of the Word Star con¬ 
figuration file with some simple changes. 
The QCONFIG.GNU (the config file) 
reads: “The first part of each line is the 
keystroke(s) to be mapped, then the Qedit 
function it is mapped to, and then a com¬ 
ment to describe the emacs mapping. All 
Qedit functions are mappable.” 

Qedit features include 

• memory swapping for DOS shells, 

• up to eight windows, 

• simultaneous multiple-file editing, 

• support for EGA (42-line) and VGA 
(50-line) displays, 

• finding and replacing text, and 

• an undelete facility. 

The program finds matching braces 


sional design artist could produce the 
same kinds of images with either pack¬ 
age, perhaps with Draw being a little 
stronger in terms of allowing the artist 
microscopic control over object pixels. 
On the other hand, not being a profes¬ 
sional artist, I preferred Designer. The 
interface was more natural to me, proba¬ 
bly because of my computer condition¬ 
ing. I doubt that you would be disap¬ 
pointed either way. 

Readers can contact Corel Systems 
Corp. at 1600 Carling Way, Ottawa, On¬ 
tario, Canada K1Z 8R7; (613) 728-8200. 
Cost: $695. 

Micrografix is located at 1303 Arapa- 
ho, Richardson, TX 75081; (214) 234- 
1769, or (800) 733-3729. Cost: $695 
(version 3.0). 

IMSI is located at 1938 Fourth St., San 
Rafael, CA 94901; (415) 454-7101. Cost: 
$149.95. 


(Corel) Reader Service 26 
(Micrografix) Reader Service 27 
(IMSI) Reader Service 28 


and parentheses and performs auto¬ 
matic indentation for C programs. It 
centers lines, wraps words, refor¬ 
mats paragraphs, and sorts text. 

Qedit is a great tool at $54.95, 
though you wouldn’t use it to write 
the great American novel. It does 
not have a complete macro program¬ 
ming language; nevertheless, this 
editor takes almost no space and al¬ 
most no memory, little time, and lit¬ 
tle money. Learning it is simple. Us¬ 
ing it is quick. Although simple 
editing is Qedit’s forte, it can do 
much more than that. This package 
is a good choice for your disk-limit¬ 
ed laptop, a window in Desqview, or 
your 486 workstation with a 300- 
Mbyte disk. 

Readers can contact Semware at 
Ste. C-3, 4343 Shallowford Rd„ 
Marietta, GA 30062-5003; (404) 
641-9002. — Quentin Fennessy, 

ITP Systems Inc. 
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NEW COMPUTER SCIENCE 

BOOKS 


OBJECT-ORIENTED DATABASES 

edited by Ez Nahouraii and Fred Petry 

This book is a collection of reprinted articles that explore 
object-oriented databases and provide a broad overview of 
current concepts, examples, and applications. It begins with 
an introduction to this rapidly advancing technology and in¬ 
cludes twenty papers organized into four sections: basic con¬ 
cepts, applications, design and implementation, and perform¬ 
ance issues. 

Sections: Object-Oriented Concepts, Object-Oriented Database 
Approaches, Implementations and Approaches to Implemen¬ 
tation Issues, Evaluation and Validation of Object-Oriented 
Databases. 

256 PAGES. MARCH 1991. HARDBOUND. ISBN 0-8186-8929-3. 
CATALOG NO. 1929 $50.00/ MEMBERS $35.00 


OTHER TITLES OF INTEREST ON 
OBJECT-ORIENTED PROG RAMM ING 


OBJECT-ORIENTED COMPUTING 
Volume 1: Concepts 
Volume 2: Implementations 

edited by Gerald Peterson 

All aspects of object-oriented computing are explored in these two 
complimentary volumes. These tutorials present the basic concepts 
of object-oriented programming, designs, databases, and architec¬ 
tures, and describe several object-oriented languages. 

VOL 1:216PAGES. - CATALOG NO. 821 $40.00 /MEMBERS$25.00 
VOL2:328 PAGES. - CATALOG NO. 822 $50.00 /MEMBERS$30.00 


DOMAIN ANALYSIS AND SOFTWARE 
SYSTEMS MODELING 

edited by Ruben Prieto-Diaz and 
Guillermo Arango 

Domain analysis addresses the questions of how to identify, 
capture, and evolve reusable information within restricted 
problem areas. This tutorial examines recent developments in 
domain analysis, includes articles on concepts, methods, and 
representations, explains systematic approaches to domain 
analysis, and discusses infrastructural aspects of reusability. 

Sections: Introduction and Overview: Domain Analysis Con¬ 
cepts and Research Directions, Conceptual Issues and Meth¬ 
ods, Representations, Support Environments, Case Studies. 

312PAGES. MAY 1991. HARDBOUND. ISBN 0-8186-8996-X. 
CATALOG NO. 1996 $70.00/MEMBERS $40.00 


ADD $5.00 PER BOOK TO COVER HANDLING CHARGES. 
PRICES ARE 20% HIGHER OUTSIDE THE U.S. AND CANADA. 


VALIDATING AND VERIFYING 
KNOWLEDGE-BASED SYSTEMS 

edited by Uma G. Gupta 

Knowledge-based-system applications through its usage of 
artificial intelligence tools and techniques demonstrate its 
great potential in solving problems in the industrial, scientific, 
and financial fields. This collection of important papers 
explores both the power and versatility of this young and 
exciting technology in its examination of state-of-the-art 
developments in expert system testing and the challenging 
area of real-time applications. 

Sections: Expert System Validation, Knowledge Base Verifica¬ 
tion, Development and Evaluation, Case Studies and Tools, 
General Topics. 

424PAGES. MAY 1991. HARDBOUND. ISBN0-8186-8995-1. 
CATALOG NO. 1995 $80.00 / MEMBERS $45.00 

DISTRIBUTED COMPUTING SYSTEMS: 
CONCEPTS AND STRUCTURES 

edited by Akkihebbal L. Ananda 
and Balasubramaniam Srinivasan 

This book is a reprint collection of 25 important papers that 
cover key topics and examine the basic concepts, problems, 
solutions, and structures of distributed computing systems. It 
also explores the design, development and implementation of 
these evolving systems. The text includes an introductory 
overview of distributed computing systems and defines their 
aims, objectives, major characteristics, physical and logical 
distributions, and potential benefits. 

Sections: Definition, Motivation, and Concepts of Distributed 
Systems, Communication Primitives for Distributed Systems, 
Distributed Operating Systems, Distributed File Systems, Dis¬ 
tributed Programming Languages. 

416PAGES. FEBRUARY 1991. HARDBOUND. ISBN0-8186-8975-0. 
CATALOG NO. 1975 $30.00/ MEMBERS $24.00 



TO ORDER 

Call or Write to: 

1951-1991 

IEEE Computer Society Press 

Customer Service Center 

48 ) 

10662 Los Vaqueros Circle 

PO Box 3014 


Los Alamitos, CA 90720-1264 

Phone: 714/ 821 -8380 FAX: 714/ 821 -4010 


7b//-free.1-800-CS-BOOKS 


Available from IEEE Computer Society Press 

























IPPS '92 Call for Papers 


Sixth International Parallel Processing Symposium 

March 23 - 26, 1992 - Beverly Hilton - Beverly Hills, California 

Sponsored by: Sm r AElli Stfp inri»£v ln cooperation with: 9cm ACM SIGARCH 


4 


THE INSTITUTE OF ELECTRICAL AND 
ELECTRONICS ENGINEERS, INC. 


Program Committee: 

Program Chair: 

Viktor Prasanna, USC 

Dharma Agrawal, North Carolina State 
University 
Lubomir Bic, UCI 
Kai Hwang, USC 

Oscar Ibarra, University of California, 
Santa Barbara 

Joseph Ja'Ja', University of Maryland 
Lennart Johnsson, Thinking Machines 
Corporation & Harvard University 
H. T. Kung, CMU 
Louis Lome, SDI/ISTO 
L. M. Patnaik, Indian Institute of Science 
Thomas Probert, Encore Computer Corp. 
John Reif, Duke University 
Sartaj Sahni, University of Florida 
J. L. C. Sanz, IBM Almaden Research 
Center 

H. J. Siegel, Purdue University 
Harold Stone, IBM Research Division 
Earl Swartzlander, University of Texas 
Benjamin Wah, University of Illinois 


Organizing Committee: 

General Chair: 

Larry Canter, Computer Systems 
Approach, Inc. 

Steering Committee Chair: 

George Westrom, Odetics, Inc. 

Finances: 

Bill Pitts, Toshiba America 
Information Systems, Inc. 

Local Arrangements: 

Susamma Barua, California State 
University, Fullerton 

Publicity: 

Sally Jelinek, Electronic Design 
Associates 

Commercial Exhibits: 

Mary Eshaghian 

Grumman Data Systems 

4015 Hancock Avenue, Suite 200 

San Diego, CA 92110-5154 

Internet: mary@gdstech.grumman.com 


The sixth annual International Parallel Processing Symposium is a 
forum for engineers and scientists throughout the world to share 
current developments in all aspects of parallel and distributed 
processing. Along with invited and submitted papers, IPPS '92 will 
offer poster sessions, tutorials, commercial exhibits, workshops and 
a Parallel Systems Fair. In 1992, the symposium is sponsored by 
the IEEE Computer Society and will be held in cooperation with 
ACM SIGARCH and the Orange County Chapter of the IEEE 
Computer Society. The Program Committee welcomes all work 
which will contribute to the state-of-the-art. Papers should 
demonstrate original unpublished research including development of 
experimental or commercial systems. Topics of interest include but 
are not limited to the following: 

Parallel & Distributed Algorithms 
Performance Modeling & Evaluation 
Interconnection Networks 
Signal & Image Processing Systems 
Parallel Architectures 
Programming Environments 


Parallelizing Compilers 
Special Purpose Processors 
Neural Networks 
Fault Tolerance 
Parallel Languages 
Mapping & Scheduling 


SUBMITTING PAPERS: All papers will be reviewed. Send six (6) 
copies of complete paper (not to exceed 20 double spaced pages; 
about 5000 words). Manuscripts must be received by September 
16, 1991. Due to the large number of anticipated submissions, 
manuscripts postmarked later than September 15, 1991 will not be 
considered. (Post overseas submissions air mail.) Notification of 
review decisions will be mailed by December 13, 1991. Camera 
ready papers are due January 17, 1992. Proceedings will be 
available at symposium. Submit manuscripts to: 

Dr. Viktor Prasanna, IPPS '92 Program Chair 
Dept, of Electrical Engineering-Systems, EEB 244 
University of Southern California 
Los Angeles, CA 90089-2562 
Internet: ipps92@ashoka.usc.edu 


WORKSHOP: The 1992 symposium will include a workshop on 
Heterogeneous Processing. To obtain further information about 
participation in this event, contact Dr. Richard Freund, Naval Ocean 
Systems Center, at 619-553-4071 or at FREUND@NOSC.MIL. 

PARALLEL SYSTEMS FAIR: As a new feature, IPPS '92 invites 
participation in a one day Parallel Systems Fair which will feature 
current parallel systems under development or available at academic, 
industrial and research lab sites. To be considered for inclusion in 
this program, submit a proposal (not to exceed 3 single spaced 
pages) to the Commercial Exhibits Chair by November 1, 1991. 
Also, those companies who would like to exhibit their products at 
the symposium should contact the Commercial Exhibits Chair. 









CONFERENCES 


Cray Research plans for 1990s outlined at European conference 


Ware Myers, Contributing Editor 

John A. Rollwagen, chair and chief ex¬ 
ecutive officer of Cray Research, got up 
very early the morning of February 6. 

The reason: He was to speak at 3:30 a.m. 
Minneapolis, Minnesota, time via tele¬ 
conferencing satellite to a late-morning 
keynote session of Supercomputing Eu¬ 
rope 91 in Stuttgart, Germany. The su¬ 
percomputing industry is facing massive 
changes, so getting up early may help in¬ 
dustry leaders cope with what’s to come. 

‘The advent of massively parallel pro¬ 
cessing ... promises unprecedented power 
and presents an unprecedented challenge to 
our industry,” he told the opening-day au¬ 
dience attending the conference sponsored 
by the Commission of European Commu¬ 
nities’ ESPRIT Program and the US De¬ 
partment of Commerce, among others. 

“For the first time in our short history, we 
are faced with the opportunity and chal¬ 
lenge of a fundamentally new architecture. 
It has become clear that this new architec¬ 
ture, which has been in the labs for more 
than a decade, is becoming a reality.” 

A few hours later, at 8:30 a.m. in Min¬ 
neapolis, Steve Nelson, Cray’s vice pres¬ 
ident for technology, addressed an after¬ 
noon Stuttgart session, also via satellite 
hookup. He presented a technical over¬ 
view of where the company is headed. 
“One key word is parallelism, and an¬ 
other is teraflops,” Nelson said. “It is the 
grand challenge of the 1990s.” 

Where Cray is now. The company is 
presently marketing the eight-processor 
Cray Y-MP/8. “We will be announcing, 
sometime in the future (not to be per¬ 
ceived as an actual announcement to¬ 
day), the Cray Y-MP/16,” Nelson said. 
Table 1 summarizes key differences be¬ 
tween the two machines. 

As for technology, “We are using sili¬ 
con circuits, with 10,000-gate arrays,” 
Nelson continued. “We have a custom 
hermetic package developed; in fact, we 
are building [the packages] in Chippewa 
Falls, Wisconsin, using thin-film tech¬ 
niques. The substrate is a 22-layer cir¬ 
cuit — about twice the number of layers 
that we have in the Cray Y-MP/8.” The 
new computer will exploit high-density 
BiCMOS memory with 1-megabyte de¬ 
vices at first and larger ones later. 

This small-scale parallelism will con¬ 
tinue to develop during the decade. 


“There will be 32-processor designs right 
up to 256 processors,” Nelson expects. 
Clock cycle time will drop from the 4 nano¬ 
seconds of the Cray Y-MP/16 to 2 ns, then 
to 1 ns. “We continue to think that large real 
shared memory — low latency and high 
bandwidth — is important.” 

In fact, memory bandwidth is a chal¬ 
lenge. “Density over the past 20 years 
has gone up many orders of magnitude,” 
he noted, “but the bandwidth in terms of 
the number of bits that come off that chip 
per second has gone up only by a factor 
of 10. It is really a time for change here.” 

No one company can drive this change 
by itself. The new DRAMs must be com¬ 
modity devices. Working with vendors, 
Cray “will be driving this interface 
change, which will be multiple bits, pipe¬ 
lining, and so forth on the DRAM part,” 
Nelson said. 

On to massively parallel. Projecting 
sustained processing speed about 15 years 
ahead, Nelson showed it increasing from 
a few gigaflops at present to about one 
teraflops. At the same time, the cost may 
drop to a few hundred dollars per mega¬ 
flops (from around $10,000). He used a 
chart to show a mid 90s “knee,” with the 
rate of change increasing sharply. 

“A lot of people believe that, when we 
can field the massively parallel designs, 
we will have the opportunity to make a 
quantum jump in performance on those 


problems that can be mapped in mas¬ 
sively parallel machines,” Nelson said. 

The best way to exploit this technolo¬ 
gy, he thinks, is to hook a massively par¬ 
allel system to a conventional supercom¬ 
puter, like the Y-MP series. “It makes 
sense to leverage [the technology we 
have developed] in the general-purpose 
machine,” he said. “In some cases, [our 
users] find that the best system to get the 
problem set up on is a Cray Y-MP, then 
they do the computation and mapping on 
the massively parallel machine.” 

“Sometimes, the setup can be a very 
large portion of the overall time, maybe 
as much as half; so, we think this is a 
good way to handle it. We have a lot of 
I/O support, peripherals, tape, disks, and 
so on in our general-purpose environ¬ 
ment. We have rugged operating sys¬ 
tems. Also we can exploit some of the 
compiler technology.” 

This combination of a massively paral¬ 
lel system and a general-purpose super¬ 
computer allows three ways of looking at 
the programming model during the peri¬ 
od of transition. (This transition “will 
surely last a decade,” Nelson estimated.) 
First, those not ready to make the transi¬ 
tion can do all their work on the super¬ 
computer as they did before. 

Second, those ready to make a start 
can search out the critical regions where 
most of the processing is done, and most 
of the parallel operations are visible, and 


Table 1. The forthcoming Cray Y-MP/16 will have more processing power than 
the current Y-MP/8. 


Machine Feature 

Y-MP/8 

Y-MP/16 

Number of processor 

8 

16 

Gigaflops (peak) 

2.7 

16.0 

Vector pipes 

1 

2 

Vector elements 

64 

128 

Memory banks 

256 

1,024 

Ports to memory 

4 (single) 

4 (double) 

Memory bandwidth/clock (words) 

17 

60 

IC count 

7,000 

6,300 

ICs/processor 

875 

400 

Logic gates/processor 

750 Kbytes 

1.25 Mbytes 
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put them onto the massively parallel 
engine. Performance will be limited by the 
data-transfer rates between the massively 
parallel and general-purpose machines. 

Third, some will choose to turn over 
essentially all their computations to the 
massively parallel processors, using the 
supercomputer (or a smaller machine) as a 
front end. Along this.transition spectrum, 
there is a place for every user. 

During the transition, users have to 
watch cost very carefully, Nelson warned. 
“You cannot have a processor node that is 
terribly expensive and multiply its cost by 
1,000 or 10,000 without getting a total cost 
that people cannot afford,” he said. 

“We can put together the hardware in a 
variety of ways. The real difficulty is 
developing the software to support what 
we do on the hardware side — both on the 
operating system and compiler side, and 
on the application side. This is where the 
work of this decade has to be centered,” 
Nelson said. 

In this connection, Rollwagen had 
pointed out previously that Cray Research 
now has twice as many software people as 
hardware people — “ironic for a company 
that started out in the Wisconsin woods 
just to build very powerful boxes.” 


CALL FOR PAPERS 


jj )IEEE Micro invites authors to submit 
7 general-interest and theme-issue papers 
for publication in 1992 issues. Themes include 
European industry, DSPs, associative memories 
and processors, and ICs for HDTV. Submit six 
copies of each paper to Editor-in-Chief Dante 
Del Corso, Dipartimento di Elettronica, 
Politecnico di Torino, C.so Duca degli Abruzzi, 
24, 10129 Torino, Italy, e-mail delcorso@ 
polito.it; or Ashis Khan, Associate EIC, Mips 
Computer Systems, 950 DeGuigne Dr., Sunny¬ 
vale, CA 94086, phone (408) 524-7171, e-mail 
' is@ mips.com. For author guidelines, 
contact Ava Marie Fulton at (714) 821-8380. 

EDBT 92, Int’l Conf. on Extending Database 
Tech.: Mar. 23-27,1992, Vienna. Sponsor: 
IEEE. Submit five copies of complete paper by 
June 20,1991, to Alain Pirotte, Philips 
Research Lab Belgium, Avenue Albert Einstein 
4, B-1348 Li 


(jjSjj) IEEE Infocom 92,11 
puter Comm.: May A 


7 puter Comm.: May 4-8, 1992, Florence, 
Italy. Cosponsor: IEEE Comm. Soc. Submit six 


copies of paper by June 30,1991, to L. Fratta, 
Politecnico di Milano, c/o Cefriel, Via 
Emanueli, 15,20126 Milano, Italy, phone 39 (2) 
2399-3578, fax 39 (2) 2399-3587, e-mail 
fratta@imicefr.bitnet; or J. Kurose, Computer 
and Information Science Dept., Univ. of 
Massachusetts, Amherst, MA 01003, phone 
(413) 545-1585, e-mail kurose@cs.umass.edu. 


fcKi IEEE Trans, on Computers plans a spe- 
NS7 cial issue on fault-tolerant computing in 
May 1992. Submit seven copies of manuscript 
by July 1,1991, to W. Kent Fuchs, 1101 W. 
Springfield Ave., Coordinated Science Lab, 
Univ. of Illinois, Urbana, IL 61801, phone (217) 
333-9731, e-mail fuchs@crhc.uiuc.edu. 


tffA PADS, Sixth Workshop on Parallel 

and Distributed Simulation: Jan. 20-22, 
1992, Newport Beach, Calif. Joint sponsors: 
IEEE et al. Submit six copies of paper by July 
1,1991, and camera-ready copy by Oct. 15, 
1991, to Marc Abrams, Computer Science 
Dept., Virginia Tech, Blacksburg, VA 24061- 
0106, phone (703) 231-8457, fax (703) 231- 
6075, e-mail abrams@cs.vt.edu. 
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Call for articles and referees for Computer 


| Computer seeks articles for inclusion in an upcoming special issue. 


Document Image Analysis Systems is the theme planned for the June 1992 
issue. Manuscripts reporting survey, original research, design and development, and 
applications of document image analysis are sought immediately. See p. 109 of the 
March 1991 issue for complete information. 

Fourteen copies of the complete manuscript are due by July 1,1991; notification 
of decisions is set for December 1,1991 ; and the deadline for submittal of the final 
version of each manuscript is February 1,1992. 

Submissions and questions should be directed to Rangachar Kasturi, Electrical 
and Computer Engineering Department, Pennsylvania State University, University 
Park, PA 16802, phone (814) 863-4254, e-mail kasturi@cmpe.psu.edu; or Lawrence 
O’Gorman, Room 3D-455, AT&T Bell Labs, Murray Hill, NJ 07974, phone (201) 582- 
7262, e-mail log@research.att.com. 


For submittal to Computer, manuscripts must not have been previously 
published or currently submitted for publication elsewhere. Each manuscript 
should be no more than 32 typewritten, double-spaced pages long, including 
all text, figures, and references. Each of the 12 copies (or otherwise 
indicated number of copies) submitted should include a cover page that 
contains the title of the article, the full name(s) and affiliation(s) of the 
author(s), complete postal and electronic address(es) of all the authors as 
well as their telephone and fax number(s), a 300-word abstract, and a list of 
keywords identifying the central issues of the manuscript’s contents. The 
final manuscript should be approximately 8,000 words in length and contain 
no more than 12 references. 

If you are willing to review articles for any special issue, please send a 
note listing your research interests to one of the guest editors listed for the 
particular issue or to Jon T. Butler, editor-in-chief of Computer, at the 
Department of Electrical and Computer Engineering, Naval Postgraduate 
School, Code EC/Bu, Monterey, CA 92943-5004, phone (408) 646-3299 or 
(408) 646-3041, fax (408) 646-2760, lnternetbutler@ece.nps.navy.mil. 


COMPUTER 



























IEEE Design & Test seeks papers (25 
double-spaced pages, including figures) 
on quality assurance issues involved in the 
design, test, and manufacture of computing 
systems. Submit five copies of QA papers by 
July 1,1991, or papers on general design, test 
and manufacturing topics by Dec. 1,1991, to M. 
d'Abreu, GE R&D, 1 River Rd., KW-C308, 
Schenectady NY 12301, phone (518) 387-7097, 
fax (518) 387-5299, e-mail dabreu@crd.ge.com. 

SETSS 92, Eighth Int’l Conf. on Software 
Eng. for Telecommunication Systems and 
Services: Mar. 30-Apr. 1, 1992, Florence, Italy. 
Sponsor: Institution of Electrical Engineers. 
Submit synopsis by July 1,1991, to IEE Conf. 
Services, Savoy Place, London WC2R OBL, 

UK, phone (071) 240-1871, fax (071) 240- 
7735. 


Int’l J. of Expert Systems: Research and 
Applications plans a special issue in March 
1992 on research in case-based expert systems. 
Submit manuscript by July 1,1991, to 
Evangelos Simoudis, AI Applications Group, 
DEC, 290 Donald Lynch Blvd., MS DLB5- 
2/B4, Marlboro, MA 01752, phone (508) 490- 
8141, e-mail simoudis@aiag.enet.dec.com. 

20th Workshop on Applied Imagery Pattern 
Recognition: Oct. 16-18, 1991, McLean, Va. 
Cosponsors: Int’l Soc. for Optical Eng., Rome 
Air Development Center. Submit abstract by 
July 1,1991, to Joan Lurie, 02/1338, TRW, 1 
Space Park, Redondo Beach, CA 90278, phone 
(213)814-8690. 


1991 Systems Evaluation and Assessment 
Tech. Workshop: Aug. 20-22,1991, Silver 
Spring, Md. Sponsors: Naval Surface Warfare 
Center, Office of Naval Tech. Submit five 
copies of position paper by July 1,1991, to 
Janet Youngblood, NSWC, Code G42,10901 
New Hampshire Ave., Silver Spring, MD 
20903-5000, phone (301) 394-3851, fax (301) 
394-1175, e-mail hwang@nswc-wo.navy.mil. 

Technical Symp. on Laser and Sensor Eng.: 

Jan. 19-24,1992, Los Angeles. Sponsor: Inf 1 
Soc. for Optical Eng. Submit abstract by July 1, 
1991, to SPIE, PO Box 10, Bellingham, WA 
98227-0010, phone (206) 676-3290, fax (206) 
647-1445 (in North Am.); SPIE, Xantener 
Strasse 22, D-1000 Berlin 15, Germany, phone 
49 (30) 883-9507, fax 49 (30) 882-2028 (in 
Europe); or SPIE, c/o OTO Research, Takeuchi 
Bldg., 1-34-12 Takatanobaba, Shinjuku-ku, 
Tokyo 160, Japan, phone 81 (03) 3208-7821, 
fax 81 (03) 3200-2889 (in the Far East, 
Australia, and New Zealand). 

11th IEEE Inf 1 Phoenix Conf. on 
v!?' Computers and Communications: Apr. 
1-3,1992, Scottsdale, Ariz. Cosponsors: IEEE 
Comm. Soc. et al. Submit five copies of 
complete paper and abstract by July 15,1991, 
and camera-ready version by Dec. 2, 1991, to 
Ming T. (Mike) Liu, Ohio State Univ., 
Computer and Information Science Dept., 2036 
Neil Ave., Columbus, OH 43210-1277, phone 
(614) 292-6552, fax (614) 292-9021, e-mail 
mike.liu@ osu.edu. 


Fourth Int’l Conf. on Strategic Soft- 
Xiy ware Systems: Mar. 10-11, 1992, 
Huntsville, Ala. Cosponsors: IEEE Computer 


Soc. Huntsville Chapter, Univ. of Alabama in 
Huntsville. Submit abstract by July 15,1991, to 
Ann H. Yelle, Univ. of Alabama in Huntsville, 
Continuing Education Division, Conferences 
(SSS-92), Bevill Center 289-A, Huntsville, AL 
35899, phone (800) 448-4035 or (205) 895- 
6372, fax (205) 895-6760. 

RIDE-TQP 92, Int’l Workshop on Research 
Issues in Data Eng. — Transaction and 
Query Processing: Feb. 2-3, 1992, Mission 
Palms, Ariz. Submit five copies of extended 
abstract by July 15,1991, to Philip S. Yu, IBM 
T.J. Watson Research Center, PO Box 704, 
Yorktown Heights, NY 10598, phone (914) 
784-7141, e-mail psyu@ibm.com. 

ICOOMS 92, Int’l Conf. on Object-Oriented 
Manufacturing Systems: May 4-6,1992, 
Calgary, Alta., Canada. Cosponsors: Soc. for 
Computer Simulation, Univ. of Calgary. Submit 
four copies of extended abstract by July 15,1991, 
to Douglas Nome, Manufacturing Eng. Division, 
Eng. Faculty, Univ. of Calgary, 2500 University 
Dr. NW, Calgary, T2N 1N4, Alta., Canada, 
phone (403) 220-5787, fax (403) 282-8406. 

J. of Computer and Software Eng. will begin 
quarterly publication in the fall of 1991 and 
seeks manuscripts on various theory and 
application topics. Publisher: Ablex. Submit 
five copies of full manuscript by July 15,1991. 
to E.K. Park, Computer Science Dept., US 
Naval Academy, Annapolis, MD 21402, phone 
(301) 267-3080, fax (301) 267-4883, e-mail 
eun@cad.usna.navy.mil. 

16th Conf. on Local Computer Net- 

works: Oct. 14-17, 1991, Minneapolis, 
Minn. Cosponsor: IEEE Computer Soc. 
Technical Committee on Computer Comm. 
Submit five copies of camera-ready version by 
Aug. 2,1991, to James F. Mollenauer, 

Technical Strategy Associates, 37 Silver Birch 
Rd., Newton, MA 02168, phone and fax (617) 
244-0077. 

12th IEEE Symp. on Real-Time Sys- 

terns: Dec. 3-6, 1991, San Antonio, 

Texas. Sponsor: IEEE Computer Soc. Technical 
Committee on Real-Time Computing. Submit 
five copies of extended abstract by Sept. 2, 
1991, to Lui Sha, Software Eng. Inst., Carnegie 
Mellon Univ., 4500 Fifth Ave., Pittsburgh, PA 
15213, phone (412) 268-5875, e-mail sha@ 
sei.cmu.edu. 

EDAC 92, European Conf. on Design 

Automation: Mar. 16-19, 1992, Brussels. 
Cosponsors: EDAC Assoc, et al. Submit nine 
copies of full manuscript by Sept. 2,1991, and 
final version by Dec. 2, 1991, to Hugo De Man, 
c/o CEP Consultants, 26-28 Albany St., 
Edinburgh EH1 3QH, UK, phone 44 (31) 557- 
2478, fax 44 (31) 557-5749. 

ICSE 92,14th Int’l Conf. on Software 

Eng.: May 11-15, 1992, Melbourne, 
Australia. Cosponsors: IEEE Computer Soc. et 
al. Submit six copies of full paper or experience 
report by Sept. 6,1991, to A.Y. Montgomery, 
Computer Science Dept., Royal Melbourne Inst, 
of Tech., PO Box 2476V, Melbourne 3001, 
Victoria, Australia, phone 61 (3) 660-2943, fax 
61 (3) 662-1617, e-mail aym@goanna.cs. 


Fifth Int’l Conf. on VLSI Design: Jan. 

4-7, 1992, Bangalore, India. Sponsor: 
VLSI Soc. of India et al. Submit six copies of 
camera-ready manuscript by Sept. 14,1991, to 
Yashwant K. Malaiya, Computer Science Dept., 
Colorado State Univ., Fort Collins, CO 80523, 
phone (303) 491-7031, fax (303) 491-2293, 
e-mail malaiya@ravi.cs.colostate.edu; or K.S. 
Raghunathan, Microelectronic and Computer 
Division, Indian Telephone Industries, 
Bangalore, 560016, India, phone 91 (812) 563- 
211, fax 91 (812)572-824. 

Micro 24, 24th ACM/IEEE Int’l Symp. 

and Workshop on Microarchitecture: 

Nov. 18-20,1991, Albuquerque, N.M. Submit 
four copies of final version by Sept. 17,1991, to 
(by geographical region) Andrew Wolfe, 
Electrical and Computer Science Dept., Carnegie 
Mellon Univ., Pittsburgh, PA 15213-3890, 
phone (412) 268-7102, fax (412) 268-2860, 
e-mail wolfe@ece.cmu.edu; Toshio Nakatani, 
IBM Japan, 5-19, Sanbancho, Chiyoda-ku, 
Tokyo 102, Japan, phone 81 (03) 288-8409, fax 
81 (03) 265-4251, e-mail nakatani@trlvm3. 
iinusl.ibm.com or nakatani@jpntscvm.bitnet; 
or Hans Mulder, Electrical Eng. Dept., Delft 
Univ. of Tech., PO Box 5031, 2600 GA Delft, 
The Netherlands, phone 31 (0) 1578-5021, fax 
31 (0) 1578-4898, e-mail hansm@duteca.et. 
tudelft.nl. 

IEEE Int’l Conf. on Wafer-Scale Inte- 
vftz gration: Jan. 22-24, 1992, San Francisco. 
Sponsors: IEEE Computer Soc., IEEE 
Components, Hybrids, and Manufacturing Tech. 
Soc. Submit six copies of full camera-ready text 
by Oct. 1,1991, to Peter W. Wyatt, MIT 
Lincoln Lab, B-153, Box 73, Lexington, MA 
02173-9108, phone (617) 981-7232 (in the 
Americas); R. Mike Lea, Brunei Univ., 
Uxbridge UB8 3PH, UK (in Europe); or Tadashi 
Sasaki, Sharp Corp., 8, Ichigaya, Hachiman- 
cho, Shinjuku-ku, Tokyo 162, Japan (in Asia). 

12th Int’l Conf. on Distributed Com- 

puting Systems: June 9-12, 1992, 
Yokohama, Japan. Cosponsor: Information 
Processing Soc. of Japan. Submit six copies of 
manuscript by Oct. 15,1991, to Joseph E. 
Urban, Computer Science and Eng. Dept., 
Arizona State Univ., Tyler Mail-ECG 252, 
Tempe, AZ 85287-5406, phone (602) 965-2774, 
fax (602) 965-2751, e-mail jurban@asuvax.eas. 
asu.edu. 

Eighth Int’l Conf. and Workshop on 
Vi? Data Eng.: Feb. 3-7,1992, Phoenix, Ariz. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Data Eng. Submit five copies of 
camera-ready version by Oct. 31,1991, to 
Forouzan Golshani, Computer Science and Eng. 
Dept., Arizona State Univ., Tempe, AZ 85287- 
5406, phone (602) 965-2855, e-mail golshani@ 
asuvax.eas.asu.edu. 

f£j^) IEA/AIE 92, Fifth Int’l Conf. on In- 

dustrial and Eng. Applications of 
Artificial Intelligence and Expert Systems: 

June 9-12,1992, Paderbom, Germany. 
Cosponsors: Univ. of Paderbom et al. Submit 
six copies of paper by Nov. 1,1991, to Fevri 
Belli, Univ. of Paderbom, Postfash 1621,4790 
Paderbom, Germany, phone 49 (5251) 60-3282, 
e-mail belli@adt.uni-paderbom.de. 
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HOT Chips in 


A Symposium on High-Performance Chips 


Stanford University, Palo Alto, California — August 26-27, 1991 

Attend HOT Chips III, a symposium on high-performance chips, which will bring together researchers and developers of 
chips used to construct high-performance workstations and systems. Enjoy the informal format offering interaction with 
speakers. The first two HOT Chips Symposiums were huge successes and prompted articles in three special issues oi 
IEEE Micro magazine. This year’s HOT Chips III will again bring you the latest developments in chip technology. 


Monday, August 26 Tuesday, August 27 


High-Performance Processors - 1 

• Viking: A Superscalar SPARC Processor 

• R4000 Technical Overview 

• High-Performance PA-RISC Processor 
for “Snakes” Workstation 

Highly Parallel Chips 

• The LIFE Family of High-Performance 
Single Chip VLIWs 

• The Message-Driven Processor 

• The TRW CPUAX Superchip: 

A 4.1 Million Transistor CMOS CPU 

High-Performance Processors - 2 

• An 80MHz 64-Bit Floating Point RISC 
Processor with Direct DRAM Support 

• The 80860XP — 2nd Generation of the i860™ 
RISC Processors Family 

• Beyond Claims of Free Transistors and 
Abundant Instruction-Level Parallelism 

Low Power and Low Cost 

• SPARC System Chipset 

• The SparKIT Chipset: 

How to Clone a Sparcstation 

• SMM, The “Virtual 386™” 

Monday Evening Reception 

Evening Panel Session 

Five Instructions Per Clock: 

Truth or Consequences 


Communications 

• A GaAs 200 Mbps 64X64 Crosspoint Chip 

• RN1: Low-Latency, Dilated, Crossbar Router 

• The NEURON Chip Family Architecture 

• The Protocol Engine Chipset 

Caches and Floating Point 

• R4000 Cache Design 
Tradeoffs and Performance 

• The Megacell Differentiated Floating Point 
Product Family 

• High Integration 2nd Level Cache 
for the i486™ CPU 

Special Processors 

• C-Cube CL950 MPEG Video 
Decoder/Processor 

• A Smart Frame Buffer 

• A High-Performance, Low-Cost Neural Chip 

High-Performance Processors - 3 

• National’s Swordfish — A Superscalar with DSP 

• HI: A Superscalar Pipelined CPU 

• The Pinnacle SPARC Module 


This is an advance program. General topics are listed 
for each session. Presentation details may change. 













Organizing Committee 


General Chairman 

Martin Freeman, Philips Research 
Program Co-Chairmen 
Forest Baskett, Silicon Graphics 
John Hennessy, Stanford University 

Treasurer 

Hasan AIKhatib, Santa Clara University 

Program Committee 


Co-Chairmen 

Forest Baskett, Silicon Graphics 
John Hennessy, Stanford University 


Registration Chairman & 

Local Arrangements Chairman 

Robert Stewart, Stewart Research 

Publicity Chairman 

Andre Goforth, NASA Ames Research Center 
Publication Chairman 

Nam Ling, Santa Clara University 


Committee Members John Mashey, MIPS 

John Crawford, Intel Teresa Meng, Stanford University 

David Ditzel, Sun Microsystems Alan Smith, U.C. Berkeley 


HOT Chips III is sponsored by the Technical Committee on 
Microprocessors and Microcomputers of the IEEE Computer Society. 




IEEE 


Registration Fees: 



postmarked by 

subsequent 


July 26th 

registration 

IEEE Computer Society 
or ACM Member 

$170 

$240 

Non-Member 

$240 

$290 

Full-Time Student 

$75 

$100 


Instead of payment by check, registration may be 
charged to VISA or MasterCard. Registration charged 
to a credit card may be faxed to Dr. Robert Stewart at 
(415) 941-6699. 

Registration Includes: 

• Attendance • Sunday evening wine and 

• One copy of the notes cheese reception 

• Two luncheons • Monday evening reception 

• Coffee breaks • Parking at Florence Moore Hall 

On-site registration is available Sunday evening at the 
wine and cheese reception, and each morning at the 
Symposium. 

For more information on registration and local arrange¬ 
ments contact Dr. Robert Stewart at (415) 941-6699 or 
r.stewart@compmail.com. 

Wine and Cheese Reception 

• Sunday, August 25 — 5:00-7:00 p.m. 

• Rodin Garden, Stanford University 

• A Guided Tour of the Statuary will be Provided. 


|~HOT Chips III Registration Form 

I Name- 

I Affiliation- 

| Mailing _ 

| Address 

| City/State/Zip- 

I Country_ 

■ Area Code/Phone #_ 

I Email Address_ 

j Membership: □ «*E □ ACM 

I Membership Number:_ 

Payment Method: 

□ ' Iheck drawn on a U.S. Bank □ VISA 

■ Make Check Payable To: .—. 

Hot Chips Symposium |_| MasterCard 

I Name on Credit Card_ 

■ Credit Card#_ 

I Expiration Date_ 

| Signature_ 

I Amount Enclosed:_ 

I Mail To: Dr. Robert G. Stewart 


I I — I Housing Stewart Research Enterprises I 

I ^ Information 1658 Belvoir Drive j 

| Requested Los Altos, CA 94024 

I_I 


Register by July 26 , 1991 for lowest rates ... 

























CALENDAR 


In the accompanying Calendar and adjoining Call for Papers, the IEEE 
Computer Society logo identifies the conferences the society is participat¬ 
ing in or sponsoring. Other conferences of interest to our readers — as well as 
their sponsors — are also listed. 

Calendar and Call for Papers notices are published free of charge, in chrono¬ 
logical order, and as space permits. 

When submitting information for inclusion in the Call for Papers section, please 
provide the following: the name of the event, the date(s), the location, the spon¬ 
sors), the deadline for submittals, and the phone and fax numbers and — if ap¬ 
plicable — the electronic address of the person to whom papers should be 
sent. 

For listings in the Calendar section, please provide the following: the event 
name, the date(s), the location, the sponsor(s), and the phone and fax numbers 
and — again, if applicable — and electronic address of the person to contact for 
complete information. 

Submitted information should arrive at Computer at least five weeks before 
the month of publication (i.e., for the August 1991 issue, send information for 
receipt by June 20, 1991) to Chuck Governale, Calendar Dept., Computer, PO 
Box 3014, Los Alamitos, CA 90720-1264, fax (714) 821-4010, e-mail 
c.governale@compmail.com. 


June 1991 


DAC 91, 28th ACM/IEEE Design 
Automation Conf., June 17-21, San 

Francisco. Contact MP Associates, 7490 Club¬ 
house Rd., Suite 102, Boulder, CO 80301, 
phone (303) 530-4333, e-mail dacinfo@dac. 


1991 ACM Int’l Conf. on Supercomputing, 
June 17-21, Cologne, Germany. Cosponsors: 
Gesellschaft fur Informatik et al. Contact Rue- 
diger Esser, FKA-ZAM, D-5170 Juelich, Ger¬ 
many, phone 49 (2461) 61-6588, fax 49 
(2461) 61-6656, e-mail zdv003@djukfal 1. 
bitnet. 

Eighth Int’l Conf. on Testing Computer 
Software, June 17-21, Washington, DC. 
Sponsor: Data Processing Management Assoc. 
Educational Foundation. Contact Genevieve 
Houston-Ludlam, Frontier Technologies, 190 
Admiral Cochran Dr., Suite 180, Annapolis, 
MD 21401, phone (301) 266-8244, fax (301) 
224-3840. 

Computer Security Foundations IV, 
sgP' June 18-20, Franconia, N.H. Sponsor: 
IEEE Computer Soc. Technical Committee on 
Security and Privacy. Contact J. Thomas 
Hargh, Secure Computing Technology, 1210 
W. County Rd. E, Arden Hills, MN 55112, 
phone (612) 482-7428, fax (612) 482-7401. 

NECC 91,12th Nat’l Educational Comput¬ 
ing Conf., June 18-20, Phoenix, Ariz. Con¬ 
tact NECC 91, Arizona State Univ., Commu¬ 
nity Services Center, Tempe, AZ 85287-0908, 
phone (602) 965-7363; or Susan Gayle, ISTE, 
1787 Agate St., Eugene, OR 97403-9905, 
phone (503) 346-2834. 


29th Meeting of the Assoc, for Computa¬ 
tional Linguistics, June 18-21, Berkeley, 
Calif. Contact Don Walker, Bellcore, MRE 
2A379, 445 South St., Box 1910, Morristown, 
NJ 07960-1910, phone (201) 829-4312, e-mail 
walker@flash.bellcore.com or bellcore! 

Supercomputing USA/Pacific 91, June 19- 

21, Santa Clara, Calif. Sponsor: Meridian Pa¬ 
cific Group. Contact MPG, 116 E. Blithedale 
Ave., Suite, 2, Mill Valley, CA 94941, phone 
(800) 879-4454, (415) 381-2255, fax (415) 
381-1451. 

29th Tech. Symp. on Advanced Information 
Interfaces, June 20, Gaithersburg, Md. Co¬ 
sponsors: Nat’l Inst, of Standards and Tech., 
ACM. Contact Mike McClimens, ACM, PO 
Box 3663, McLean, VA 22103-3663, phone 
(703) 883-7697. 

1991 IEEE Int’l Symp. on Information The¬ 
ory, June 23-28, Budapest, Hungary. Contact 
Anthony Ephremides, Electrical Eng. Dept., 
Univ. of Maryland, College Park, MD 20742, 
phone (301) 405-3641, arpanet tony @ eng. 
umd.edu. 

ICANN 91, Int’l Conf. on Artificial Neural 
Networks, June 24-28, Espoo, Finland. Co¬ 
sponsors: IEEE Neural Networks Council, 

Int’l Neural Network Soc. Contact Congress 
Management Systems, PO Box 151, SF-00141 
Helsinki, Finland, phone 358 (0) 175-355, fax 
358 (0) 170-122. 

Compass 91, Sixth Conf. on Computer As¬ 
surance, June 24-28, Gaithersburg, Md. Co¬ 
sponsors: IEEE Aerospace and Electronics 
Soc., IEEE Nat’l Capital Area Council. Con¬ 
tact Dolores R. Wallace, Nat’l Inst, of Stan¬ 


dards and Tech., Gaithersburg, MD 20899, 
phone (301) 975-3340, e-mail wallace@swe. 
ncsl.nist.gov. 


® FTCS 21, 21st Int’l Symp. on Fault- 
Tolerant Computing, June 25-27, 

Montreal. Sponsor: IEEE Computer Soc. 
Technical Committee on Fault-Tolerant Com¬ 
puting. Contact Janusz Rajski, McGill Univ., 
Electrical Eng. Dept., 3480 University St., 
Rm. 633, Montreal, Que., Canada H3A 2A7, 
fax (514) 398-4470, e-mail rajski@spock.ee. 
mcgill.ca. 


First Int’l Conf. on Artificial Intelligence in 
Design, June 25-27, Edinburgh, Scotland. 
Contact Helen Hodge or Tom Whiting, Butter- 
worth Scientific, Westbury House, Bury 
Street, Guildford, Surrey, GU2 5BH, UK, 
phone (0483) 300-966, fax (0483) 301-563. 


Fifth Int’l Conf. on Logic Programming, 
June 25-28, Paris. Cosponsors: Assoc, of 
Logic Programming et al. Contact Inst. Nat’l 
de Recherche en Informatique et en Automa- 
tique (INRIA), Service des Relations Ex- 
terieures, Domaine de Voluceau — Rocquen- 
court, BP 105, 78153 Le Chesnay Cedex, 
France, phone 33 (l)-39-63-55-00, fax 33 (1) 
39-63-56-38, e-mail iclp@minos.inria.fr. 


ICAIL 91, Third Inf 1 Conf. on Artificial 
Intelligence and Law, June 25-28, Oxford, 
UK. Cosponsors: Soc. for Computer and Law 
(UK) et al. Contact Carole Hafner, College of 
Computer Science, Northeastern Univ., Bos¬ 
ton, MA 02115, e-mail hafner@corwin.ccs. 
northeastem.edu; or Richard Susskind, Ma¬ 
sons, Solicitors, 30 Aylesbury St., London 
EC1R 0ER, UK, fax 44 (071) 490-2545. 


Arith 10,10th Symp. on Computer 
Arithmetic, June 26-28, Grenoble, 
France. Cosponsors: ACM et al. Contact Jean- 
Michel Muller, Lab. LIP-IMAC, Ens. Lyon, 
69364 Lyon Cedex 07, France, phone 33 (72) 
72-8229. 


CGI 91, Ninth Inf 1 Conf. on Com- 
puter Graphics, June 26-28, Cam¬ 
bridge, Mass. Cosponsors: Computer Graphics 
Soc. et al. Contact Barbara Dullea, Ocean 
Eng. Dept., MIT Rm. 5-435, 77 Massachusetts 
Ave., Cambridge, MA 02139, phone (617) 
253-7799, fax (617) 253-8125, e-mail 


Second Inf I Conf. on Local Communica¬ 
tion Systems, June 26-28, Palma, Spain. 
Sponsor: Int’l Federation for Information Pro¬ 
cessing. Contact Ramon Puigjaner, Univ. de 
les Illes Balears, Carretera de Valldemossa, 
km. 7.6, 07071 Palma, Spain, phone 34 (71) 
207111, fax 34 (71) 758061 or 200741, e-mail 
dmilan91@ps.uib.es. 

12th Inf I Conf. on Application and Theory 
of Petri Nets, June 26-28, Aarhus, Denmark. 
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Sponsor: Aarhus Univ. Contact Kurt Jensen, 
Computer Science Dept., Aarhus Univ., Den¬ 
mark, phone (45) 8612-7188, fax (45) 8613- 
5725, e-mail icpn@daimi.au.dk. 

Third Int’l Conf. on Software Eng. and 
Knowledge Eng., June 27-29, Skokie, Ill. 
Sponsors: Knowledge Systems Inst, et al. 
Contact W.D. Hurley, Computer Science 
Dept., Alumni Hall, Univ. of Pittsburgh, Pitts¬ 
burgh, PA 15260, phone (412) 624-8843, 
e-mail hurley@cs.pitt.edu. 

Sixth IEEE Conf. on Structure in Complex¬ 
ity Theory, June 30-July 3, Chicago. Contact 
N. Immerman, Computer and Information Sci¬ 
ence Dept., Univ. of Massachusetts, Amherst, 
MA 01003, e-mail immerman@cs.umass.edu. 


July 1991 


IEE Bicentennial Conf. on Computing, July 
1-3, London. Contact Conf. Services, Institu¬ 
tion of Electrical Engineers, Savoy Place, 
London WC2R OBL, UK, phone 44 (71) 240- 
1871, fax 44 (71)240-7735. 

/£|^| CAR 91, Fifth Int’l Symp. on Com- 
puter-Assisted Radiology, July 3-6, 

Berlin. Sponsor: Technical Univ. of Berlin. 
Contact Heinz U. Lemke, Inst, for Technical 
Computer Science, Sekr CG-FR3-3, Franklin- 
strasse 28-29, D-1000, Berlin 10, Germany, 
phone 49 (30) 314-73100; or Michael H. 
Rhodes, Toshiba America MRI, 280 Utah 
Ave., South San Francisco, CA 94080, phone 
(415) 875-2909. 


Operating Systems of the 90s and Be- 
yond, July 8-12, Dagstuhl, Germany. 
Contact Arthur I. Karshmer, New Mexico 
State Univ., Computer Science Dept., PO Box 
30001, Dept. 3CU, Las Cruces, NM 88003- 
0001, phone (505) 646-2312, fax (505) 646- 
6218. 


Second Int’l Conf. on Industrial and Ap¬ 
plied Math., July 8-12, Washington, DC. 
Contact Soc. for Industrial and Applied Math. 
Conf. Coordinator, Dept. CC0590, 3600 Uni¬ 
versity City Science Center, Philadelphia, PA 
19104-2688, phone (215) 382-9800, fax (215) 
386-7999, e-mail siamconfs@ wharton. 
upenn.edu. 

IJCNN 91, Int’l Joint Conf. on Neural Net¬ 
works, July 8-12, Seattle. Cosponsors: IEEE, 
Int’l Neural Network Soc. Contact IJCNN 91, 
UW Extension, GH-25, 5001 25th Ave. NE, 
Seattle, WA 98185, phone (206) 543-2310, 
fax (206) 685-9359. 


ICGA 91, Fourth Int’l Conf. Symp. on Ge¬ 
netic Algorithms, July 13-16, San Diego, 
Calif. Contact Richard K. Belew, Computer 
Science and Eng. Dept., C-014, Univ. of Cali¬ 
fornia at San Diego, La Jolla, CA 92093, 
e-mail rik@cs.ucsd.edu. 


Park, CA 94025-3496, phone (415) 328-3123, 
fax (415) 321-4457, e-mail ncai@aaai.org. 

IAAI 91, Third Conf. on Innovative Appli¬ 
cations of Artificial Intelligence, July 15-17, 

Anaheim, Calif. Sponsor: Am. Assoc, for Ar¬ 
tificial Intelligence. Contact IAAI 91, AAAI, 
445 Burgess Dr., Menlo Park, CA 94025- 
3496, phone (415) 328-3123, fax (415) 321- 
4457, e-mail iaai@aaai.org. 

Symp. on Gigabit Networks, July 15-17, 

Washington, DC. Contact Albert Vezza or 
Roxane Purvis, Computer Science Lab, MIT, 
545 Technology Sq., Rm. 103, Cambridge, 

MA 02139, phone (617) 253-5852, fax (617) 
258-8682, e-mail roxane@hq.lcs.mit.edu. 

LICS 91, Sixth IEEE Symp. on Logic 
in Computer Science, July 15-18, Am¬ 
sterdam. Cosponsors: IEEE Computer Soc. 
Technical Committee on Math. Foundations 
of Computing et al. Contact Albert R. Meyer, 
MIT Computer Science Lab, Rm. NE43-315, 
545 Technology Sq., Cambridge, MA 02139, 
phone (617) 253-6024, fax (617) 253-3480. 

Second Int’l Information Research Conf., 
July 15-18, Cambridge, UK. Sponsors: British 
Library Research and Development Dept, 
Univ. of Pittsburgh. Contact Karen Merry, 
British Library R&D Dept., 2 Sheraton St„ 
London W1V 4BH, UK, phone 44 (071) 323- 
7050, fax 44 (071) 323-7251. 

ECOOP 91, Fifth European Conf. on Ob¬ 
ject-Oriented Programming, July 15-19, 

Geneva. Contact Oscar Nierstrasz, Centre 
Univ. d’lnformatique, 12 rue du Lac, CH- 
1207, Geneva, Switzerland, fax 41 (22) 735- 
39-05, e-mail oscar@cui.unige.ch; or Karl 
Lieberherr, Northeastern Univ., College of 
Computer Science, Cullinane Hall, Boston, 

MA 02115, phone (617) 437-2077, fax (617) 
437-5121, e-mail Iieber@corwin.ccs. 
northeastem.edu. 


JWCC 6, Sixth Joint Workshop on Com¬ 
puter Comm., July 17-19, Kitakyushu, Fuku¬ 
oka, Japan. Contact Makoto Takizawa, Infor¬ 
mation and Systems Eng. Dept., Tokyo Denki 
Univ., Hatoyama, Saitama 350-03, Japan, 
phone 81 (492) 96-2911 ext. 2406, fax 81 
(492) 96-6185, e-mail taki@takilab.k. 
dendai.ac.jp. 

SCSC 91, 1991 Summer Computer Simula¬ 
tion Conf., July 22-24, Baltimore. Sponsor: 
Soc. for Computer Simulation. Contact SCS, 
PO Box 17900, San Diego, CA 92117-7900, 
phone (619) 277-3888, fax (619) 277-3930. 


SIGGraph 91, July 28-Aug. 2, Las Ve- 

\2&' gas. Sponsor: ACM. Contact Assoc, for 
Computing Machinery, 11 W. 42nd St., New 
York, NY 10036, phone (212) 869-7440. 


August 1991 


Santa Cruz, CA 95064, fax (408) 459-3074, 
e-mail colt@cis.ucsc.edu. 


Crypto 91, Aug. 11-15, Santa Barbara, 
Calif. Cosponsors: Int’l Assoc, for 
Cryptologic Research et al. Contact Burt 
Kaliski, Crypto 91, RSA Data Security, 10 
Twin Dolphin Dr., Redwood City, CA 94065, 
phone (415) 595-8782, fax (415) 595-1873, 
Internet: burt@rsa.com. 


ICPP 91, 20th Int’l Conf. on Parallel Pro¬ 
cessing, Aug. 12-16, St. Charles, Ill. Sponsor: 
Pennsylvania State Univ. Contact Tse-yun 
Feng, Electrical Eng. East Bldg., Pennsylvania 
State Univ., University Park, PA 16802, 
phone (814) 863-1469, fax (814) 865-7065, 
e-mail tfeng@ecl.psu.edu. 

/£|^j Hot Chips III Symp., Aug. 26-27, 

Stanford, Calif. Sponsor; IEEE Comput¬ 
er Soc. Technical Committee on Microproces¬ 
sors and Microcomputers. Contact Martin 
Freeman, Philips Research Labs, Signetics MS 
02, 811 E. Arques Ave., Sunnyvale, CA 
94086, phone (408) 991-3591, fax (408) 991- 
4077, e-mail mfreeman@sierra.stanford.edu; 
or Melissa Anderson, Silicon Graphics, 2011 
N. Shoreline Blvd., PO Box 7311, Mountain 
View, CA 94039-7311, phone (415) 335- 
1565, fax (415) 965-7651, e-mail mda@sgi. 


Tencon 91,1991 IEEE Region 10 
Conf., Aug. 26-30, New Delhi, India. 
Contact H.L. Bajaj, B-101 Hillview Apts., 
Vasant Aihar, New Delhi 110057, India, 
phone 91 (11) 36-0412, fax 91 (11)36-1018; 
or A.L. Lakshminarasimhan, AT&T Bell 
Labs, 480 Red Hill Rd., No. HR 2E030, Mid¬ 
dletown, NJ 07748, phone (201) 615-4524. 

® 1991 Workshop on the High-Order 
Language Theorem-Proving System 
and Its Applications, Aug. 27-30, Davis, Ca¬ 
lif. Sponsors: IEEE Computer Soc. Technical 
Committee on Design Automation et al. Con¬ 
tact Myla Archer, Computer Science Division, 
Univ. of California at Davis, Davis, CA 
95616, phone (916) 752-7583, fax (916) 752- 
4767, e-mail archer@eecs.ucdavis.edu. 

SSD 91, Second Symp. on Large Spa¬ 
vin tial Databases, Aug. 28-30, Zurich, 
Switzerland. Contact Hans-J. Schek, Inst, fur 
Information Systeme, Eth Zentrum, CH-8092 
Zurich, Switzerland, phone 41 (1) 254-7240, 
fax 41 (1) 262-3973, e-mail schek@inf. 
ethz.ch. 


September 1991 


/Vm Int’l Conf. on Application-Specific 
Array Processors, Sept. 2-4, Barcelo¬ 
na, Spain. Sponsor: Princeton Univ. Contact 
S.Y. Kung, Electrical Eng. Dept., Princeton 
Univ., Princeton, NJ 08554, phone (609) 258- 
3780, fax (609) 258-3745. 


AAAI 91, Ninth Nat’l Conf. on Artificial In¬ 
telligence, July 14-19, Anaheim, Calif. Spon¬ 
sor: Am. Assoc, for Artificial Intelligence. 
Contact AAAI 91, 445 Burgess Dr., Menlo 


Fourth Workshop on Computational 
Learning Theory, Aug. 5-7, Santa Cruz, 
Calif. Contact Jean McKnight, Computer and 
Information Science, Applied Sciences Bldg., 


Eurographics 91, Conf. of the European As¬ 
soc. for Computer Graphics, Sept. 2-6, Vi¬ 
enna. Contact Eurographics 91, do Intercon¬ 
vention, Austria Center Vienna, A-1450 


June 1991 
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VLDB 91,17th Int’l Conf. on Very 
Large Data Bases, Sept. 3-6, Barcelo¬ 
na, Spain. Sponsors: IEEE Computer Soc. 
Technical Committee on Data Eng. et al. Con¬ 
tact Guy M. Lohman, IBM Almaden Research 
Center, Dept. K55, Bldg. 801, 650 Harry Rd„ 
San Jose, CA 95120-6099, Internet lohman@ 
ibm.com, Bitnet lohman @ almaden. 

Euro VHDL 91, Second European 
Conf. on Very High Density Logic, 
Sept. 8-11, Stockholm. Sponsor: Int’l Federa¬ 
tion for Information Processing. Contact Jean 
Mermet, IMT Technopole de Chateau- 
Gombert, 13451 Marseille, Cedex 13, France, 
phone 33 (91) 05-44, fax 33 (91) 05-4343. 

I ^j^ l Compsac 91,15th Int’l Computer 
v-5^ Software and Applications Conf., 
Sept. 11-13, Tokyo. Cosponsor: Information 
Processing Soc. of Japan. Contact Stephen S. 
Yau, Univ. of Florida, CIS Dept., Rm. 301, 
Gainesville, FL 32611, phone (904) 335-8006 
or (904) 392-1212, fax (904) 392-1220, e-mail 
yau@cis.ufl.edu. 

Fourth Artificial Intelligence Symp., 
Sept. 20-21, Fredericton, N.B., Canada. 
Sponsor: Univ. of New Brunswick. Contact 
Bradford G. Nickerson, Computer Science 
Faculty, Univ. of New Brunswick, PO Box 
4400, Fredericton, N.B., Canada E3B 5A3, 
phone (506) 453-4566, fax (506) 453-3566, 
e-mail bgn@unb.ca. 

First Int’l Workshop on the Econom- 
ics of Design and Test, Sept. 23-25, 

Austin, Texas. Sponsor: ACM. Contact Mag- 
dy Abadir, MCC CAD Program, 3500 W. Bal- 
cones Center Dr., Austin, TX 78759, phone 
(512) 338-3611, fax (512) 338-3600; or A.P. 
Ambler, Brunei Univ., Dept, of Electrical 
Eng. and Electronics, Uxbridge, Middx, UB8 
3PH, UK, phone (44) 895-74000, fax (44) 
895-58728. 

ASIC 91, Fourth IEEE Int’l Applica¬ 
nt^ tion-Specific Integrated Circuits 
Conf., Sept. 23-27, Rochester, N.Y. Sponsor: 
IEEE Rochester Section. Contact Lynne M. 
Engelbrecht, ASIC 91, 170 Mt. Read Blvd., 
Rochester, NY 14611, phone (716) 328-2310, 
fax (716) 436-9370. 

Pacific Rim Int’l Symp. on Fault- 
vSp' Tolerant Systems, Sept. 26-27, Ka¬ 
wasaki, Japan. Sponsor: Inst, of Electrical, In¬ 
formation, and Comm. Eng. Contact Sachio 
Naito, Electrical Eng. Dept., Nagaoka Univ. 
of Tech., 1603-1 Kamitomioka, Nagaoka, Ni¬ 
igata, 940-21, Japan, phone 81 (258) 46-6000, 
ext. 5110, fax 81 (258) 46-6506. 

i£|^j IEEE/ACM Int’l Conf. on Developing 
and Managing Expert System Pro¬ 
grams and Projects, Sept. 30-Oct. 2, Wash¬ 
ington, DC. Contact Jerald Feinstein, Mitre, 
7325 Colshire Dr„ McLean, VA 22102, phone 
(703) 883-6236, fax (703) 821-0701; or Larry 
Medsker, Computer Science and Information 
Systems Dept., American Univ., Washington, 
DC 20016. 


10th Symp. on Reliable Distributed 
Systems, Sept. 30-Oct. 2, Pisa, Italy. 
Contact Luca Simoncini, IEI-CNR, Via S. 
Maria 46, 56100 Pisa, Italy, phone 39 (50) 
553-159, fax 39 (50) 554-342; or Ozalp 
Babaoglu, Dip. di Matematica, Univ. di Bolo¬ 
gna, Piazza di Porta S. Donato, 5, 40127 Bo¬ 
logna, Italy, phone 39 (51) 354-430, fax 39 
(51) 354-490, e-mail ozalp@dm.unibo.it. 

First Int’l Conf. on Document Analy- 
n5p^ sis and Recognition, Sept. 30-Oct. 2, 

Saint-Malo, France. Cosponsors: Assoc. Fran- 
caise pour la Cybemetique Economique et 
Technique et al. Contact Guy Lorette, IRISA- 
Campus Universitaire de Beaulieu, 35042 
Rennes Cedex, France, phone (33) 9936-2000, 
fax (33) 9938-32. 


October 1991 

IEEE Workshop on Visual Motion, 
Oct. 6-9, Princeton, N.J. Contact Peter 
Burt, David Sarnoff Research Center, 201 
Washington Rd., Princeton, NJ 08540, e-mail 
burt@vision.sarnoff.com. 

OOPSLA 91, Sixth Conf. on Object- 
Oriented Programming Systems, Lan¬ 
guages, and Applications, Oct. 6-11, Phoe¬ 
nix, Ariz. Sponsor: ACM. Contact John Rich¬ 
ards, IBM T.J. Watson Research Center, PO 
Box 704, Yorktown Heights, NY 10598, 
phone (914) 784-7616; or Dan Steinbach, 
Steinbach and Co., 1 Pleasant St., Maynard, 
MA 01754, phone (508) 897-8661 

® CSEE 91, Fifth Conf. on Software 
Eng. Education, Oct. 7-8, Pittsburgh. 
Sponsor: Software Eng. Inst. Contact James E. 
Tomayko, SEI, Carnegie Mellon Univ., 4500 
Fifth Ave., Pittsburgh, PA 15213-3890, phone 
(412) 268-6806, fax (412) 268-5758, e-mail 
jet@sei.cmu.edu. 

11th IEEE Symp. on Mass Storage 
nix Systems, Oct. 7-10, Monterey, Calif. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Mass Storage Systems and 
Tech. Contact Bernard T. O’Lear, NCAR, PO 
Box 3000, Boulder, CO 80307, phone (303) 
497-1268, fax (303) 497-1137. 

Symp. on Testing, Analysis, and Veri- 
fication, Oct. 8-10, Victoria, B.C., Can¬ 
ada. Sponsors: IEEE Computer Soc., ACM 
SIGSoft. Contact Nancy Leveson, Computer 
Science Dept., Univ. of California, Irvine, CA 
92717, phone (714) 856-5517, e-mail nancy@ 
ics.uci.edu. 

First Int’l Conf. on Artificial Intelli- 
Y3P' gence Applications on Wall St., Oct. 
9-11, New York City. Sponsor: Polytechnic 
Univ., Brooklyn. Contact Mary Bianchi, Poly¬ 
technic Univ., 333 Jay St., Brooklyn NY 
11201, phone (718) 260-3360, fax (718) 260- 
3136. 

/£3^| IEEE Int’l Workshop on Visual Lan¬ 
vin guages, Oct. 9-11, Kobe, Japan. Spon¬ 
sor: IEEE Computer Soc. Contact Shi-Kuo 
Chang, Computer Science Dept., Univ. of 


Workshop on Experimental Distrib- 
uted Systems, Oct. 12, Huntsville, Ala. 
Contact Raif M. Yanney, TRW, 1 Space Park, 
DH2/2328, Redondo Beach, CA 90278, phone 
(213) 764-6033. 

RIDT 91, Second Inf 1 Workshop on 
Raster Imaging and Digital Typogra¬ 
phy, Oct. 14-15, Boston. Cosponsor: Univ. of 
Massachusetts. Contact Robert A. Morris, 
Math, and Computer Science Dept., Univ. of 
Massachusetts at Boston, Harbor Campus, 
Boston, MA 02125-3393, phone (617) 287- 
6466, e-mail ridt91-request@cs.umb.edu. 

ICCD 91, IEEE Inf 1 Conf. on Com- 
puter Design, Oct. 14-16, Cambridge, 
Mass. Cosponsors: IEEE Computer Soc. and 
IEEE Circuits and Systems Soc. Contact 
ICCD 91, IEEE Computer Soc., 1730 Massa¬ 
chusetts Ave. NW, Washington, DC 20036- 
1903, phone (202) 371-1013. 

16th Conf. on Local Computer Net 
works, Oct. 14-17, Minneapolis, Minn. 
Cosponsor: IEEE Computer Soc. Technical 
Committee on Computer Comm. Contact 
James F. Mollenauer, Technical Strategy As¬ 
sociates, 37 Silver Birch Rd., Newton, MA 
02168, phone and fax (617) 244-0077. 

Conf. on Software Maintenance, Oct. 
14-17, Sorrento, Italy. Cosponsor: 

IEEE. Contact Vaclav Rajlich, Computer Sci¬ 
ence Dept., Wayne State Univ., Detroit, MI 
48202, phone (313) 577-5423, fax (313) 577- 
6868, e-mail vtr@cs.wayne.edu; John Mun¬ 
son, Computer Science Dept., Univ. of West 
Florida, Pensacola, FL 32514; or Malcolm 
Munro, Centre for Software Maintenance, 
Univ. of Durham, Durham, DH1 3LE, 
England, phone 44 (091) 374-2634, e-mail 
malcolm.munro@uk.ac.durham. 

@ Int’l Workshop on Object Orienta¬ 
tion in Operating Systems, Oct. 17-18, 

Palo Alto, Calif. Sponsor: IEEE Computer 
Soc. Technical Committee on Operating Sys¬ 
tems. Contact Vincent Russo, Computer Sci¬ 
ence Dept., Purdue Univ., West Lafayette, IN 
47907, phone (317) 494-6008, fax (317) 494- 
0737. 

Visualization 91, Oct. 22-25, San 

Diego, Calif. Sponsor: IEEE Computer 
Soc. Technical Committee on Computer 
Graphics. Contact Bruce Brown, Oracle, 500 
Oracle Pkwy., MD 40P12, Redwood Shores, 
CA 94065, phone (415) 726-0983, fax (415) 
506-7200; or Gregory M. Nielson, Computer 
Science Dept., Arizona State Univ., Rural 
Road and University, Tempe, AZ 85287-5406, 
phone (602) 965-2785. 

Sixth Int’l Workshop on Software 
Specification and Design, Oct. 25-26, 

Como, Italy. Contact C. Ghezzi, Dip. di Elet- 
tronica, Politecnico di Milano, Piazza Leonar¬ 
do Da Vinci 32, 20133 Milano, Italia, 
e-mail relett24@imipoli.bitnet: or Jean-Pierre 
Finance, CRIN, Campus Scientifique, BP 239 
54000 Nancy, France, e-mail finance@loria. 
crin.fr. 
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ILPS 91, Int’l Logic Programming 
Symp., Oct. 28-31, San Diego, Calif. 
Sponsor: Assoc, of Logic Programming. Con¬ 
tact Kenneth Kahn or Vijay Saraswat, Xerox 
PARC, 3333 Coyote Hill Rd„ Palo Alto, CA 
94304, Kahn’s phone (415) 494-4390, Saras- 
wat’s phone (415) 494-4747, fax (415) 494- 
4334, e-mail ilps91@parc.xerox.com. 


ITC 91, Int'l Test Conf., Oct. 28-Nov. 

1, Nashville, Tenn. Cosponsor: IEEE 
Philadelphia Section. Contact Doris Thomas, 
PO Box 264, Mt. Freedom, NJ 07970, phone 

(201) 895-5260, fax (201) 896-7265; or IEEE 
Computer Soc., 1730 Massachusetts Ave. 

NW, Washington, DC 20036-1903, phone 

(202) 371-1013. 


Third NASA Symp. on VLSI Design, Oct. 
30-31, Moscow, Idaho. Cosponsors: IEEE 
Section of Spokane, Wash., Univ. of Idaho 
NASA Space Eng. Research Center. Contact 
Judy Wood, NASA SERC, Univ. of Idaho, 
Moscow, ID 83843, phone (208) 885-6500, 
fax (208) 885-7579, e-mail jwood@groucho. 
mrc.uidaho.edu. 


ISCIS VI, Sixth Int’l Symp. on Com- 
puter and Information Sciences, Oct. 
30-Nov. 2, Ankara, Turkey. Sponsors: Bilkent 
Univ., IEEE Turkey Chapter. Contact Mehmet 
Baray, Bilkent Univ., Computer Eng. and In¬ 
formation Sciences Dept., Bilkent 06533 Am 
kara, Turkey, phone (90) 4-266-4133, fax 90 
(4) 266-4127, e-mail iscis@trbilun.bitnet. 


November 1991 


25th Asilomar Conf. on Signals, Sys- 
terns, and Computers, Nov. 4-6, Pacif¬ 
ic Grove, Calif. Sponsors: Naval Postgraduate 
School, San Jose State Univ. Contact Frederic 
J. Harris, Electrical and Computer Eng. Dept., 
San Diego State Univ., San Diego, CA 92182- 
0190, (619) 594-6162. 

® TAI 91, Third IEEE Computer Soc. 

Conf. on Tools for Artificial Intelli¬ 
gence, Nov. 5-8, San Jose, Calif. Contact 
Benjamin Wah, Coordinated Science Lab, MC 
228, Univ. of Illinois, 1101 W. Springfield 
Ave., Urbana, IL 61801-3082, phone (217) 
333-3516, fax (217) 244-1764, e-mail wah% 
aquinas@cso.uicu.edu; or Nikolaus G. Bour- 
bakis, 4138 Moonflower Ct„ San Jose, CA 
95135, phone (408) 270-3455. 

Conf. on Organizational Computing 
Systems, Nov. 5-8, Atlanta. Sponsors: 
IEEE Computer Soc. Technical Committee on 
Office Automation, ACM SIGOIS, Int’l Fed¬ 
eration for Information Processing. Contact 
Frederick H. Lochovsky, Hong Kong Univ. of 
Science and Tech., Computer Science Dept., 
5/F World Shipping Center, 7 Canton Rd., 
Hong Kong, phone (852) 302-1642, fax (852) 
736-8801. 

ICCAD 91, IEEE Int’l Conf. on Com- 
puter-Aided Design, Nov. 11-14, Santa 
Clara, Calif. Cosponsor: IEEE Circuits and 
Systems Soc. Contact ICCAD 91 Secretary, 


MP Associates, 7490 Clubhouse Rd., Suite 
102, Boulder, CO 80301, phone (303) 530- 
4562. 


Micro 24, 24th ACM/IEEE Int’l 
Symp. and Workshop on Microarchi¬ 
tecture, Nov. 18-20, Albuquerque, N.M. Con¬ 
tact Yashwant K. Malaiya, Computer Science 
Dept., Colorado State Univ., Fort Collins, CO 
80523, phone (303) 491-7031, fax (303) 491- 
2293, e-mail malaiya@ravi.cs.colostate.edu. 


Supercomputing 91, Nov. 18-22, Albu- 
querque, N.M. Cosponsor: ACM. Con¬ 
tact Raymond L. Elliott, Computing and 
Comm. Div., MS B260, Los Alamos Nat’l 
Lab, Los Alamos, NM 87545, phone (505) 
667-1449, fax (505) 665-4361, e-mail rle@ 
lanl.gov; or Supercomputing 91, IEEE Com¬ 
puter Soc., 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone (202) 
371-1013. 


15th Western Educational Computing 
Conf., Nov. 21-22, Los Angeles. Sponsor: 
Calif. Educational Computing Consortium. 
Contact Gary Penders, Dodd Hall, UCLA, Los 
Angeles, CA 90024. 


December 1991 


Third IEEE Int’l Symp. on Parallel 
/ and Distributed Processing, Dec. 1-5, 


This has got to go! 



IEEE Computer Graphics and Applications 
announces its contest to redesign that 10-year- 
old logo and bring CG&A into the future with a 
brave new look. CG&A seeks the best computer¬ 
generated graphic presentation of its name. Just 
send one laser proof and a disk of your work in 
a popular graphic standard. 

The winner receives $100 and a subscription to 
CG&A. Up to three finalists will also receive 
subscriptions and be published. The deadline for 
all entries is October 15,1991. 

For official entry form and more details write to: 

CG&A Contest 

IEEE Computer Society 

10662 Los Vaqueros Circle 

Los Alamitos, CA 90720-1264 

(714) 821-8380 Fax (714) 821-4010 


Computer Architecture/ 

VLSI Lead Engineer 

The Advanced Computing Architecture group of The MITRE 
Corporation's Washington Signal Processing Technical Center 
seeks a Lead Engineer to participate in research projects as 
well as consult on government acquisition of advanced com¬ 
puting systems. Current projects involve the development of 
high-performance specialized computer architectures, VLSI 
and board-level implementation of new computers, simula¬ 
tion and analysis of architectural alternatives, and evaluation 
of advanced processors for use in specific applications. 

Qualifications for this high-visibility position include an 
MS or PhD in Electrical Engineering or Computer Science, 
plus five years' experience. Knowledge of computer archi¬ 
tecture and experience with simulation and evaluation meth¬ 
ods are essential. Familiarity with VLSI techniques and 
architectures, and experience with VLSI and board-level 
implementation are desirable, along with software and sys¬ 
tem design background. 

An independent, not-for-profit organization, MITRE 
works in the public interest, solving complex technical prob¬ 
lems by providing system engineering, technical assistance, 
system integration and acquisition support to government 
and civil agencies. In addition to competitive salaries, we 
offer a comprehensive benefits package. 

For confidential consideration, please forward your 
resume to: The Office of Human Resources, Section 
M691, The MITRE Corporation, 7525 Colshire Drive, 
McLean, VA 22102. We are an equal opportunity/ 
affirmative action employer. U.S. Citizenship required. 

MITRE 















Dallas. Sponsors: IEEE Computer Soc., IEEE 
Dallas Section, ACM SIGArch. Contact Sartaj 
Sahni, CIS Dept., CSE 301, Univ. of Florida, 
Gainesville, FL 32611, phone (904) 392-1527, 
fax (904) 392-1220; or Behrooz Shirazi, Univ. 
of Texas at Arlington, Computer Science Eng. 
Dept., Box 19015, Arlington, TX 76019-0015, 
phone (817) 273-3605, fax (817) 273-2548, 
e-mail shirazi@evax.utarl.edu. 

|£ji| 12th IEEE Symp. on Real-Time Sys- 
terns, Dec. 3-6, San Antonio, Texas. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Real-Time Computing. Contact 
Jane S.W. Liu, Computer Science Dept, Univ. 
of Illinois, 1304 W. Springfield Ave., Urbana, 
IL 61801, phone (217) 333-0135, e-mail 
janeliu@cs.uiuc.edu. 

Int'l Conf. on Parallel and Distri- 
Inited Information Systems, Dec. 4-6. 

Miami Beach, Fla. Cosponsors: IEEE Com¬ 
puter Soc. et al. Contact Amit Sheth, Bellcore, 
1J-210, 444 Hoes Ln., Piscataway, NJ 08854, 
phone (908) 699-3300, fax (908) 699-9011, 
e-mail amit@ctt.bellcore.com. 

® 1991 Winter Simulation Conf., Dec. 

8-11, Phoenix, Ariz. Sponsor: ACM. 
Contact Robert Crain, Wolverine Software, 
4115 Annandale Rd„ Suite 200, Annandale, 
VA 22003. 

World Congress on Expert Systems, 
Dec. 16-19, Orlando, Fla. Cosponsors: 
Int’l Assoc, of Knowledge Engineers et al. 
Contact World Congress on Expert Systems, 
c/o Congress Secretariat, Congrex (USA), 
7315 Wisconsin Ave., Suite 404E, Bethesda, 
MD 20814, phone (301)469-3355, fax (301) 
469-3360. 


Sponsors: IEEE Computer Soc., IEEE Compo¬ 
nents, Hybrids, and Manufacturing Tech. Soc. 
Contact Peter W. Wyatt, MIT Lincoln Lab, 
B-153, Box 73, Lexington, MA 02173-9108, 
phone (617) 981-7232. 


January 1992 


February 1992 


Fifth Int’l Conf. on VLSI Design, Jan. 
Y5^ 4-7, Bangalore, India. Sponsor: VLSI 
Soc. of India et al. Contact Asoke K. Laha, 
Cadence Design Systems, Systems Division, 2 
Lowell Research Center Dr., Lowell, MA 
01852-4995, phone (508) 934-0233, fax (508) 
441-1109, e-mail laha@cadence.com; or Lalit 
M. Patnaik, Computer Science and Automa¬ 
tion, Indian Inst, of Science, Bangalore, 
560012, India, phone 91 (812) 342-451, 
e-mail lalit%vigyan@shakti.emet.in. 

i£3^j Hawaii Int’l Conf. on Systems Sci- 
Y§? ences, Jan. 7-10. Koloa, Hawaii. Co¬ 
sponsors: IEEE, ACM. Contact Luqi, Comput¬ 
er Science Dept, Naval Postgraduate School, 
Monterey, CA 93940, phone (408) 646-2468. 

PADS, Sixth Workshop on Parallel 
yI^ and Distributed Simulation, Jan. 20- 

22, Newport Beach, Calif. Joint sponsors: 
IEEE, ACM, Soc. for Computer Simulation. 
Contact Paul Reynolds, Computer Science 
Dept., Olsson Hall, Univ. of Virginia, Charlot¬ 
tesville, VA 22903, phone (804) 924-1039, 
e-mail pfr@ louisxiv.ipc.virginia.edu. 

IEEE Int’l Conf. on Wafer-Scale In- 
YS^ tegration, Jan. 22-24, San Francisco. 


® Eighth Int’l Conf. and Workshop on 
Data Eng., Feb. 1-7, Phoenix, Ariz. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Data Eng. Contact (for the con¬ 
ference) Nick J. Cercone, Center for Systems 
Sciences, Simon Fraser Univ., Burnaby, B.C., 
Canada V5A 1S6, phone (604) 291-3229, 
e-mail nick@cs.sfu.ca; or (for the workshop 
on research issues) Clement Yu, Electrical 
Eng. and Computer Science Dept., Univ. of 
Illinois at Chicago, Chicago, IL 60680, phone 
(312) 996-2318, fax (312) 413-0024. 

Compcon Spring 92, Feb. 24-28, San 

Y5^ Francisco. Contact Compcon Spring 92, 
IEEE Computer Soc., 1730 Massachusetts 
Ave. NW, Washington, DC 20036-1903, 
phone (202) 371-1013. 


Third Int’l Conf. on Data and Knowl- 
edge Systems for Manufacturing 
Eng., Mar. 9-13. Cosponsors: Assoc. Fran- 
caise pour la Cybernetique Economique et 
Technique et al. Contact INSA, 20 Av. Albert 
Einstein, 69621 Villeurbanne, France, phone 
33 (72) 438-172, fax 33 (72) 440-800. 

Fourth Int’l Conf. on Strategic Soft- 
Y5^ ware Systems, Mar. 10-11, Huntsville. 
Ala. Cosponsors: IEEE Computer Soc. Hunts¬ 
ville Chapter, Univ. of Alabama in Huntsville. 
Contact Ann H. Yelle, Univ. of Alabama in 
Huntsville. Continuing Education Division, 
Conferences (SSS-92), Bevill Center 289-A, 
Huntsville, AL 35899, phone (800) 448-4035 
or (205) 895-6372, fax (205) 895-6760. 

EDAC 92, European Conf. on Design 
Yl^ Automation, Mar. 16-19, Brussels. Co¬ 
sponsors: EDAC Assoc, et al. Contact EDAC 
92 Secretariat, CEP Consultants, 26-28 Alba¬ 
ny St., Edinburgh EH1 3QH, UK, phone 44 
(31) 557-2478, fax 44 (31) 557-5749. 

Int’l Symp. on Parallel Processing, 
Mar. 30-Apr. 2, Beverly Hills, Calif. 
Contact Larry H. Canter, Computer Systems 
Approach, 1140 S. Raymond Ave., Suite B, 
Fullerton, CA 92631, phone (714) 738-3414. 
fax (714) 738-3470. 


April 1992 


Martinez, Univ. of Arizona, Electrical and 
Computer Eng. Dept., Tucson, AZ 85721, 
phone (602) 621-6174, e-mail martinez% 
ecevax@rvax.ccit.arizona.edu; or Joseph Ur¬ 
ban, Computer Science and Eng. Dept., Arizo¬ 
na State Univ., Tyler Mail-ECG 252, Tempe, 
AZ 85287-5406, phone (602) 965-2774, fax 
(602) 965-2751, e-mail jurban@asuvax.eas. 


ICCL 92, Int’l Conf. on Computer 
Y5^ Languages, Apr. 20-23, San Francisco. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Computer Languages. Contact 
Mario Barbacci, Software Eng. Inst., Carnegie 
Mellon Univ., Pittsburgh, PA 15213, phone 
(412) 268-7704, fax (412) 268-5758. 

Third Workshop on Workstation Op- 
Y5^ erating Systems, Apr. 23-24. Sponsor: 
IEEE Computer Soc. Technical Committee on 
Operating Systems. Contact Joseph Boykin, 
Encore Computer, 257 Cedar Hill St., Marl¬ 
borough, MX 01752, phone (508) 460-0500, 
fax (508) 485-0709. 


May 1992 


PCCC 92, 11th IEEE Int’l Phoenix 
yI^ Conf. on Computers and Communi¬ 
cations, Apr. 1-3, Scottsdale, Ariz. Cospon¬ 
sors: IEEE Comm. Soc. et al. Contact Ralph 


CHI 92, Conf. on Human Factors in 
Y5^ Computing, May 3-7, Monterey, Calif. 
Sponsor: ACM. Contact Assoc, for Comput¬ 
ing Machinery, 11 W. 42nd St., New York, 
NY 10036, phone (212) 869-7440. 

IEEE Infocom 92, 11th Conf. on 
\£S Computer Comm., May 4-8, Florence, 
Italy. Cosponsor: IEEE Comm. Soc. Contact 
L. Fratta, Politecnico di Milano, c/o Cefriel, 
Via Emanueli, 15, 20126 Milano, Italy, phone 
39 (2) 2399-3578, fax 39 (2) 2399-3587, 
e-mail fratta@imicefr.bitnet; or J. Kurose, 
Computer and Information Science Dept., 
Univ. of Massachusetts, Amherst, MA 01003, 
phone (413) 545-1585, e-mail kurose@cs. 
umass.edu. 


Comp Euro 92, IEEE Int’l Conf. on 
Y§^ Advanced Computer Tech., Reliable 
Systems, and Applications, May 4-8, The 

Hague, The Netherlands. Cosponsors: IEEE 
Region 8, IEEE Benelux. Contact G.J. Arink, 
Philips Medical Systems, PO Box 10.000, 
5680 DA Best, The Netherlands, phone 31 
(40) 762-060. 

ICSE 92, 14th Int’l Conf. on Software 
yI^ Eng., May 11-15, Melbourne, Austra¬ 
lia. Cosponsors: IEEE Computer Soc. et al. 
Contact A.Y. Montgomery, Computer Science 
Dept., Royal Melbourne Inst, of Tech., PO 
Box 2476V, Melbourne 3001, Victoria, Aus¬ 
tralia, phone 61 (3) 660-2943, fax 61 (3) 662- 
1617, e-mail aym@goanna.cs.rmit.oz.au. 

® 22nd Int’l Symp. on Multiple-Valued 

Logic, May 27-29, Sendai, Japan. 
Sponsors: IEEE Computer Soc. Technical 
Committee on Multiple-Valued Logic. Con¬ 
tact Tatsuo Higuchi, EE Dept., Tohuku Univ., 
Aoba, Aramaki, Sendai 980, Japan, phone 
(022) 222-1800. 
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The Eighth IEEE Conference on Artificial Intelligence for Applications 

Monterey, California, March 2-6, 1992 ■---- 


PRELIMINARY 
CALL FOR 
PARTICIPATION 



■/645\ 40 YEARS OF SERVICE 

I IEEE COMPUTER SOCIETY 


The conference is devoted to the application of artificial intelligence techniques to 
real-world problems. Two kinds of papers are appropriate: case studies of knowl¬ 
edge-based applications that solve significant problems and stimulate the develop¬ 
ment of usefiil techniques, and papers on AI techniques and principles that underlie 
knowledge-based systems, and in turn, enable more ambitious real-world applica¬ 
tions. This conference provides a forum for such synergy between applications and 
Al techniques. 

Papers describing significant unpublished results are solicited in two areas: 

• Applications Papers. Contributions stemming from the general areas of indus¬ 
try, science and engineering, business, government, law, etc. Application papers 
must: (1) Justify the use of the AI technique, based on the problem definition and 
an analysis of the application’s requirements; (2) Explain how AI technology was 
used to solve a significant problem; (3) Describe the status of the implementa¬ 
tion; (4) Evaluate both the effectiveness of the implementation and the technique 

Short papers describing systems in use (up to 1,000 words, extended abstract) 
will also be accepted for presentation in these application tracks. 

• Enabling Technology Papers. Contributions focusing on techniques and princi¬ 
ples that facilitate the development of practical knowledge based systems that 
can be scaled to handle increasing problem complexity. Topics include, but are 
not limited to: knowledge representation, reasoning, search, knowledge acquisi¬ 
tion, learning, constraint programming, planning, validation and verification, pro¬ 
ject management, natural language processing, speech, intelligent interfaces, inte¬ 
gration, problem-solving architectures, programming environments and general 

Papers should be limited to 5000 words. Papers significantly longer than this will not 
be reviewed. The first page of the paper must contain die following information 
(where applicable) in the order shown: 

• Tide. 

• Author’s name and affiliation (specify student status). 

• Contact information (name, postal address, phone and email address). 

• Abstract: A 200 word abstract that includes a clear statement describing the 
paper’s original contributions and what new lesson is imparted. 

• AI topic: One or more terms describing the relevant AI areas, e.g., knowledge ac¬ 
quisition, explanation, diagnosis, etc. 

• Domain area: One or more terms describing the problem domain area, e.g., me¬ 
chanical design, factory scheduling, education, medicine, etc. 

• Language/Tool: Underlying programming languages, systems and tools used. 

• Status: Development and deployment status, as appropriate. 

• Effort: Person-years of effort put into developing the particular aspect of the pro¬ 
ject being described. 

• Impact: A 20 word description of estimated or measured (specify) benefit of the 
application developed. 

Papers will be accepted in two forms: long papers and short papers. Papers accepted 
for publication will be alloted seven pages (long papers) or four pages (short papers) 
in the conference proceedings. The best papers accepted will be considered for a 
special issue of IEEE EXPERT to appear late in 1992. Application has been made to 
reserve a special issue of IEEE Transactions on Knowledge and Data Engineering 
(TDKE) for publication of the best enabling technology papers. IBM will sponsor an 
award of $1,500 for the best student paper at the conference. 


In addition to papers, we will be accepting the following types of submissions: 

• Proposals for Panel Discussions. Provide a brief description of the topic (1000 
words or less). Indicate the membership of the panel and interest in organiz¬ 
ing/moderating the discussion. 

• Proposals for Tutorial Presentations. Proposals for the three hour tutorials of 
both an introductory and advanced nature are requested. Topics should relate to 
the management and technical development of useful artificial intelligence appli¬ 
cations. Tutorials which analyze classes of applications in depth or examine tech¬ 
niques appropriate for a particular class of applications are of particular interest. 
Each tutorial proposal should include the following: 

• Detailed topic outline and extended abstract (about 3 pages). 

• Intended audience and assumed background knowledge. 

• Half-page synopsis of focus, topics, and benefits to audience. 

• Full professional vita (including lecture/tutorial experience and a one-para- 
graph summary.) 

• Proposals for Workshops. Proposals are sought for one day workshops to be 
held in conjunction with the conference. These workshops can focus on a spe¬ 
cific application domain (e.g. aerospace applications) or on a technical subarea 
(e.g. intelligent real time problem solving). Workshop organization and atten¬ 
dance will be governed by the organizers. Submit proposals to the workshop 

IMPORTANT DATES 

• August 30, 1991: Six copies of papers, and four copies of all the proposals are 
due. Submissions not received by that date will be returned unopened. Electroni¬ 
cally transmitted materials will not be accepted. 

• October 25,1991: Author notifications mailed. 

• December 11,1991: Accepted papers due to IEEE. Accepted tutorial notes due to 
Tutorial Chair. 

• March 2-3,1992: Conference tutorial program. 

• March 4-6,1992: Conference technical program. 

Submit Papers and Panels to: 

Jan Aikins 
Aion Corporation 
101 University Avenue 
Palo Alto, CA 94301 
Phone: 415-328-9595 
Fax: 415-328-0624 
Email: Aikins@cup.portal.com 
Submit Tutorial Proposals to: 

Daniel O’Leary 
Graduate School of Business 
University of Southern California 
Los Angeles, CA 90089-1421 
Phone: 213-740-4856 
Fax: 213-747-2815 

For registration and additional conference information, contact: 

CAIA-92 

IEEE Computer Society 
1730 Massachusetts Avenue, NW 
Washington, DC 20036-1903 
Phone: 202-371-1013 


Submit Workshop Proposals to: 

Don McKay 
UNISYS 

70 E. Swedesford Road 

Paoli, PA 19301 

Phone: 215-648-2256 

Fax: 215-648-2288 

Email: Mckay@PRC.UNISYS.COM 














CAREER OPPORTUNITIES 


RATES: $12.00 per line, (ten lines mini¬ 
mum). Average five typeset words per 
line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified Adver¬ 
tising, COMPUTER Magazine, 10662 
Los Vaqueros Circle, PO Box 3014, Los 
Alamitos, CA 90720-1264; (714) 821- 
8380; fax:(714) 821-4010. 

In order to conform to the Age Discrimina¬ 
tion in Employment Act and to discourage 
age discrimination, COMPUTER may reject 
any advertisement containing any of these 
phrases or similar ones: "...recent college 
grads,.,/' "...1-4 years maximum experi¬ 
ence...," "...up to 5 years experience," or 
"...10 years maximum experience." COM¬ 
PUTER reserves the right to append to any 
advertisement without specific notice to the 
advertiser. Experience ranges are suggested 
minimum requirements, not maximums. 
COMPUTER assumes that since advertisers 
have been notified of this policy in advance, 
they agree that any experience require¬ 
ments, whether stated as ranges or 
otherwise, will be construed by the reader 
as minimum requirements only. 


ASIAN INSTITUTE OF 
TECHNOLOGY (AIT) 

The Division of Computer Science invites 
applications for long term and visiting faculty 
positions, particularly in information systems 
and software engineering. Applicants should 
have a Ph. D. in Computer Science or closely 
related fields. Duties include research, 
teaching and supervising graduate students. 
Rank and salary commensurate with experi¬ 
ence and qualification. 

AIT is an autonomous, non-profit gradu¬ 
ate school supported internationally and 
located near Bangkok. Bangkok is rapidly 
growing into a commercial and cultural hub 
of Asia. The Institute offers a good research 
environment. Facilities include supermini¬ 
computers, SUN and SONY NEWS work¬ 
stations. MAC-11 as well as PCs, all networked 
and world-wide connection available. 

Applications will be considered as received 
and recruiting will continue until all positions 
are filled. Applicants should send a resume, 
a transcript and the names of three refer¬ 
ences to: Vice President for Academic Af¬ 
fairs. AIT, P.O. Box 2754, Bangkok 10501, 
Thailand (vw@ait.th). 


SOFTWARE ENGINEERS 

Carnegie Group, Inc. seeks experienced 
professionals to design and develop 
knowledge-based systems applications in 
C/UNIX. Scheduling/planning algorithm 
design and implementation exp. desirable. 
Exp. with X/Motif, client/server models. 
IPC, rdbms models and telecommunications 
a plus. Call or write today! 

Carnegie Group, Inc. 

5 PPG Place, Dept. A-10 
Pittsburgh, PA 15222 
412/642-6900 ext. 554 


SOFTWARE ENGINEER 

Software Engineer for computer software 
consulting company in Central Ohio. Highly 
technical systems software development on 
assigned projects for customers in software 
industry. Analyze business procedures to 
specify logical or mathematical operation to 
be performed by various units and/or com¬ 
prehensive computer programs and opera¬ 
tions to be performed by technical person¬ 
nel. Prepare technical reports, memoranda 
and instructional manuals. Perform system 
testing, integration, debugging and main¬ 
tenance. Responsible for design and devel¬ 
opment of a customized database system 
using IPCS (Inter Process Communication 
System), fundamentals and principals of 
database management system: Display in¬ 
terface for the network of SUN work-stations 
running X-Windows and OPENLOOK user 
interface: programming in C and C ++ 
languages: Software product configuration, 
build and delivery using Configuration 
Management System. Job requires M.S. 
Degree in Computer Science and two years 
experience as Software Engineer/Systems 
Analyst. The two years experience must be 
in software development (at least one year of 
which must be in ORACLE database man¬ 
agement system): UNIX System V: and C 
language. One year of the experience must 
be in UNIX System V utilities, including 
IPCS. and CMS (Configuration Manage¬ 
ment System). Six months of experience 
must be in X-Windows. User Interface 
(OPENLOOK or OSF/Motif) and C + + 
language. 40 hr./wk.: overtime as needed: 
8:30a m.-5:30p.m. Salary: $57.915.60/yr. 
Must have proof of legal authority to work 
permanently in United States. Send resume 
in duplicate (NO CALLS) to S. Holton. 
JO # 1260263, Ohio Bureau of Employment 
Services. P.O. Box 1618. Columbus. Ohio 
43216. 

An Equal Opportunity. Affirmative Action 
Employer. 


INDIANA UNIVERSITY EAST 
RICHMOND, INDIANA 
Computer Science 

Indiana University East is seeking qualified 
faculty to fill a tenure track position in com¬ 
puter science beginning fall 1991. The suc¬ 
cessful applicant will have a strong commit¬ 
ment to teaching and learning and a doctor¬ 
ate completed or in progress in computer 
science or a related field. The position also 
requires a commitment to professional de¬ 
velopment and service. Salary range to 
$40K depending on qualifications. A mini¬ 
mum of one year of practical technical ex¬ 
perience in applied computer science is 
preferred, 

The smallest of six regional campuses in 
the Indiana University system, IU East is a 
computer campus with 2000 students and 
offers a varied selection of associate degrees 
and a limited selection of four year degrees. 

Interested persons should send a letter of 
application, curriculum vitae, unofficial copy 
of graduate transcript, and names and ad¬ 
dresses of three references to: Dr. Thomas 
Osgood. Computer Science Search and 
Screen. Indiana University East. 2325 
Chester Boulevard. Richmond. IN 47374- 
1289 (317) 973-8214. Women and minori¬ 
ties are urged to apply. Indiana University 
East is an EEO / AA institution. 


ENDOWED CHAIR IN ELECTRICAL 
ENGINEERING 
AT GEORGIA TECH 

The Georgia Institute of Technology is 
seeking candidates for the Joseph M. Pettit 
Chair in the School of Electrical Engineering. 
Applications and nominations for this en¬ 
dowed chair are now being accepted. It is ex¬ 
pected that the chair holder will play a prin¬ 
cipal role in the definition and development 
of future programs in the area of computer 
engineering and/or closely related areas. 
Candidates must have a record of distin¬ 
guished performance and well established 
potential for providing leadership in research 
and instructional program development. 
Salary and program development funds avail¬ 
able for support of this distinguished position 
are fully competitive. Resumes and nomina¬ 
tions should be submitted by September 2. 
1991 and addressed to: 

Director 

School of Electrical Engineering 
Georgia Institute of Technology 
Atlanta, GA 30332-0250 
Georgia Tech is an equal opportunity, affir¬ 
mative action employer. 
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TECHNICAL ENGINEER 

Company seeks Technical Engineer to 
design, develop, configure and implement 
hardware systems; provide technical support 
and training; some accounting software 
development. 

Require Master of Science in Computer 
Science; require one year experience in the 
job offered or one year experience in the 
related occupation of Civil Engineer; require 
one advance course or experience in 
graphics; one course or experience in PE2, 
ASSEMBLY and PASCAL languages. 

40 hour work week; $2,500 per month. If 
qualified, apply at the Texas Employment 
Commission. Houston, Texas, or send 
resume to the Texas Employment Commis¬ 
sion, TEC Building, Austin, Texas 78778, 
J.O. *6139063. Ad Paid by an Equal 
Employment Opportunity Employer. 


NORTHEAST LOUISIANA 
UNIVERSITY 

Department of Computer Science 

Applications are invited for a tenure track 
position in a CSAB accredited computer 
science program, beginning in September 
1991. Candidates should have a Ph.D. in 
computer science with emphasis in software 
engineering and a strong commitment to 
teaching. Teaching load is 6-9 hours with a 
competitive salary and a twenty year retire¬ 
ment program. Applications will be accepted 
until position is filled. Applicants should send 
a resume, transcripts, and three references 
to Dr. A.D. Magoun, Chair. Search Com¬ 
mittee, Northeast Louisiana University, De¬ 
partment of Computer Science, Monroe, 
LA 71209-0575; phone (318) 342-1852. 

Northeast is an equal opportunity affirma¬ 
tive action employer. 


SOFTWARE ENGINEER 

Design and develop graphical user inter¬ 
faces in C + + using X/Motif; develop 
custom screens, menu system and state 
machine drivers; help administer our local 
area network of UNIX workstations. 

M.S. in Computer Science. One year of 
experience in the job offer or one year of 
related experience in object oriented pro¬ 
gramming utilizing C+ + , X/Motif, UNIX, 
networking and system administration. 
Knowledge of distributed processing. Yearly 
salary: $48,000. Apply at the Texas Employ¬ 
ment Commission. Dallas, Texas, or send 
resume to the Texas Employment Commis¬ 
sion. TEC Building, Austin, Texas 78778, 
J.O. 6344602. Ad Paid by an Equal Em¬ 
ployment Opportunity Employer. 


WASHINGTON UNIVERSITY 

Washington University in St. Louis seeks 
qualified candidates for the position of Pro¬ 
fessor and Chair of the Department of Com¬ 
puter Science, with a desired starting date of 
July 1, 1991. We are interested in candi¬ 
dates with a strong research record, with a 
dedication to excellence in undergraduate 
and graduate education and with a demon¬ 
strated potential for administration and 
leadership. 

The Department has an excellent under¬ 
graduate program as well as a strong and ex¬ 
panding graduate program. The primary re¬ 
search concentrations are in distributed 
systems, advanced communication networks 
and intelligent computer systems with an 
emphasis on visualization as a tool in each 
case. The Department plans to continue 
building on these areas of strength as well as 
expanding into new areas. There are 15 
regular faculty in the Department and 85 
graduate students, as well as an excellent 
technical support staff and a large pool of af¬ 
filiate faculty. Departmental laboratory 
facilities are very good and include a visuali¬ 
zation laboratory, a systems prototyping lab, 
an NCUBE parallel computer, a variety of 
compute servers and ubiquitous workstations. 

Washington University has a longstanding 
commitment to the principle that all can¬ 
didates should be afforded equal opportuni¬ 
ty regardless of age, race, sex or physical 
disability. Candidates must send a cur¬ 
riculum vitae and a list of references to: Pro¬ 
fessor C.I. Byrnes. Search Committee for 
the Computer Science Chair, Campus Box 
1040, Washington University. One Brook¬ 
ings Drive, St. Louis, MO 63130. 


PROGRAMMER ANALYST: To develop 
and port software packages to different 
operating systems and architectures. Our 
software is custom designed for the welding 
industry. The candidate will port software 
from the present Virtual Management Sys¬ 
tem (VMS) platform to the UNIX platform. 
Candidate will analyze the present system 
and the VMS operating system it runs on 
and make changes to the present system to 
run on the UNIX system. Candidate will con¬ 
duct indepth research on hardware specifica¬ 
tions to make our software have a better 
price/performance ratio. Candidate will also 
develop instruction manuals and reports ex¬ 
plaining the detailed operations of the soft¬ 
ware on the UNIX platform. Candidate will 
also research into the hardwares available. 
Candidate will be developing programs 
needed in addition to existing programs to 
run software on a UNIX platform. Masters 
Degree in Computer Science and 6 months 
Computer related Experience required. 
$25,330 per year, 40 hours per week, 8:00 
a.m. to 5:00 p.m. SEND RESUMES/ 
TRANSCRIPTS TO: JOB *0427327, 
ATTN: GARYLYTHGOE, BILLINGS JOB 
SERVICE, 1425 BROADWATER, SUITE 
E. BILLINGS, MT 59102. 


IOWA STATE UNIVERSITY 

The Department of Electrical Engineering 
and Computer Engineering invites applica¬ 
tions for positions in Computer Engineering. 
Preference will be given to individuals with 
expertise in computer networks or distri¬ 
buted systems. Applicants at both junior and 
senior levels will be considered. Responsibili¬ 
ties include teaching, research, and out¬ 
reach. Salary and rank are commensurate 
with qualifications and experience. Appli¬ 
cants must possess a Ph.D. with a demon¬ 
strated potential for excellence in teaching 
and research. Positions open September 1, 
1991 and will remain open until filled. Ap¬ 
plicants should send a resume and the name 
of at least three references to: Dr. John La- 
mont. Chairman, Faculty Search, Depart¬ 
ment of Electrical Engineering and Com¬ 
puter Engineering, 201 Coover Hall, Iowa 
State University, Ames, Iowa, 50011, Iowa 
State University is an Equal Opportunity/ 
Affirmative Action Employer. Internet: 
lamont@isuee 1 ,ee .iastate.edu. 



WIN $10,000!!! 

... and a free trip to exhibit at 
The Smithsonian Institution in 
Washington, D.C. 

A National Search for 
computer-based applications to 
help persons with physical or 
learning disabilities is being 
conducted by The Johns 
Hopkins University with grants 
from the National Science 
Foundation and MCI 
Communications Corporation. 

A grand prize of $10,000 and 
100 other prizes will be 
awarded for systems, devices 
and computer programs 
developed by Professionals, 
Amateurs, and Students. Entry 
deadline is August 23,1991. 

For an entry blank write to: 

CAPD, P.O. Box 1200 
Laurel, MD 20723 


June 1991 


109 














BOOK REVIEWS 


Editor: Alan Kaminsky, Rochester Institute of Technology, One Lomb Memorial Dr., PO Box 9887, Rochester, NY 14623-0887 


Computer Communication Systems, Volume 1: Data Circuits, Error 
Detection, Data Links 

Henri Nussbaumer, translated by John C.C. Nelson (John Wiley & Sons, West Sussex, England, 1990, 270 pp„ $54.95) 


Computer communications often are 
puzzling, but books about the field 
shouldn’t be. Luckily, I like computer 
communications, because if I were just 
starting out, this book’s puzzles would 
kill my interest. The first puzzle about 
this book is who the audience is, and 
other puzzles include what kind of book 
it is and what use can be made of it. 

The introduction says the book, de¬ 
rived from courses given to computer en¬ 
gineering students, is “for those with a 
basic background in data processing who 
wish to increase their depth of knowl¬ 
edge in the area of teleprocessing.” (The 
cover notes explain that teleprocessing is 
computer communication systems.) 
However, the book requires a back¬ 
ground in hardware circuits and fairly 
strong familiarity with discrete mathe¬ 
matics, which beginners in data process¬ 
ing probably wouldn’t have. 

Beginners usually get tutorials, sur¬ 
veys, or textbooks. Is this book supposed 
to be one of those? 

The uneven presentation is not good for 
a tutorial or a survey. Some parts are 
overly simple, while others rapidly fire dif¬ 
ficult formulas and details without ade¬ 
quate explanation or derivation. For this 
book to be useful, other introductory sur¬ 
veys are needed to provide the missing 
structure and breadth, and some in-depth 
materials are required to explain the book’s 
technical details. But, few beginners are 
teased into further study by this kind of 
puzzle. Instead, the frustration of trying to 
figure out how to understand it may block 
any interest beginners might have. 

Students might have to buy whatever 
the professor lists, but if they buy this 
book, they won’t be getting a textbook. It 
lacks exercises, questions, summaries, 
and other elements of a standard text¬ 
book. However, after the four rambling 
chapters, there is a relatively short bibli¬ 
ography that includes several foreign- 
language references and an index. 

So what is this book, and who is its 
audience? 

I suspect this book started as French 
lecture notes listing key points for engi¬ 
neering students — points explained in ei¬ 
ther the lectures or references. The French 
notes might be useful for French-speaking 
engineering students, but its English ver¬ 


sion, lacking necessary explanations, is a 
book largely without an audience. 

Whether the book started as such lec¬ 
ture notes or not, the choppy style — 
with little in the way of overviews, sum¬ 
maries, or transitions — is hard to fol¬ 
low. While reading it, though, I was re¬ 
minded of something familiar. I realized 
that the book is similar to the collection 
of quick references that most data com¬ 
munications professionals develop over 
time — the file or notebook that has pin 
assignment tables, character tables, pack¬ 
et or message layouts, and other odds 
and ends that are part of the toolkit.This 
book might provide a starting point for 
such a collection, at least for the physical 
and data-link layers and error detection. 

The first chapter, an introduction to 
computer communications vocabulary 
and concepts, needs supplementation 
from other introductions or surveys. 

The second chapter, which describes 
the physical connection of data circuits, 
also needs supplements to explain and tie 
together the book’s pieces, which do in¬ 
clude a 5-bit Baudot code table, a null- 
modem wiring diagram, V-series modem 
descriptions, and verbal traces of the 
X.21 and X.20 state diagrams. The short 
V-series descriptions are not compared, 
just stated. Also, the effect of all this on 
the network is never really explained. 

The next chapter also needs help from 
outside articles to provide different 
methods of performing and using error 
detection and correction codes. The 
book’s description of this interesting 
topic is given mostly in terms of sche¬ 
matic hardware and formulas without 
derivation or explanation. One section 
starts to consider the use of software for 
handling polynomial codes, then it pulls 
a constant table into existence by refer¬ 
ring to a circuit diagram. It recommends 
using such a table and two exclusive ORs 
rather than complex software. Then, 
there is a list of polynomial and cyclic 
codes providing the generating polyno¬ 
mials and somewhat cryptic comments 
on some properties of the cyclic codes. 
Without comparisons or comments on 
choosing from this list to match usage, 
the chapter then ends. 

The final chapter gives a quick peek at 
binary synchronous communication, 


high-level data-link control, and syn¬ 
chronous data-link control, and ends with 
a short comment about Open Systems In¬ 
terconnection service primitives for the 
network/data-link layer interface. The 
range of data-link protocols in use is just 
barely mentioned, without useful com¬ 
parisons and contrasts. The chapter con¬ 
cludes the book by enhancing the im¬ 
pression that here are some unstructured, 
unpolished pieces of a book. 

You might expect a new book on com¬ 
puter communications to provide recent 
information on the Integrated Services 
Digital Network, local area networks, or 
other popular media. This book gives a 
slight nod to LANs, but doesn’t provide 
useful information about them. The 
“pipeline” for this book — English 
sources up to 1986 and a French version 
published in 1987 — make this “new” 
book somewhat out-of-date in a fast¬ 
changing field. 

As a translated work, this is fairly 
smooth. However, the language used is 
“fat,” or overly wordy. Even if transla¬ 
tion pays by the word, that’s no reason 
the style of writing can’t be improved. 

This book has some useful information 
— ranging from character code charts to 
short lists of CCITT V-series modems. 
Unfortunately, the lack of a clear frame¬ 
work and the uneven level of presenta¬ 
tion make this a badly flawed collection 
of pieces. It is also incomplete, even 
though it takes more pages to ramble 
through fewer details than other intro¬ 
ductory works. 

The field has several good introducto¬ 
ry texts against which any newcomer 
must be measured (for example, Andrew 
S. Tanenbaum, Computer Networks, 
Prentice Hall, 1981, and William Stall¬ 
ings, Data and Computer Communica¬ 
tions, Macmillan, 1985), and this one 
doesn’t measure up. The elements in the 
collection need basic work done on them 
before they become a real book — and 
this hasn’t been done. As for the puzzle 
of why an unfinished book was pub¬ 
lished, that’s one the publishers and au¬ 
thor should have solved. 

Mike Barker 

Cosmo Securities Co. Ltd. 

Nishinomiya, Japan 
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Communication Systems for Industrial Automation 

Michael G. Rodd and Farzin Deravi (Prentice Hall, New York, 1989, 119 pp., $43.20) 


This book emerges from CIM (com¬ 
puter-integrated manufacturing), which 
may be described as various factory- 
distributed computer systems combined 
into an effective information-processing 
“megamachine.” The keys to this effec¬ 
tiveness are a distributed-but-integrated, 
consistent database and communication 
among participating computing systems. 
Appropriate man-machine interfaces are 
also necessary. 

The book emphasizes the communica¬ 
tion aspects of CIM rather than tackling 
the problem of databases and their char¬ 
acteristics. The introduction provides a 
CIM-related background for presentation 
of essential material on data communica¬ 
tion. The authors issue a position state¬ 
ment that 

The aim of this book is not to provide de¬ 
tailed design information, but rather to pro¬ 
vide users of the technology with sufficient 
insight to be able to specify their require¬ 
ments in a meaningful way. 

Thus, the book addresses various kinds 
of CIM users, managers, and supervisors 
rather than designers, implementers, or 
engineers, even though the preface states 
otherwise. Furthermore, I don’t think de¬ 
signers and implementers would find the 
book particularly useful in their jobs. 
Those who design or implement LANs 
(local area networks) have already mas¬ 
tered this kind of knowledge. Therefore, 
the book would be of little value to any¬ 
one with such a background. 

On the other hand, other technically 
oriented people may benefit from it be¬ 
cause the authors treat fundamental ques¬ 
tions in a clear and systematic fashion. 

The most important requirement for 
communication systems in factory auto¬ 
mation is fast response. The authors ar¬ 
gue that “in many aspects of CIM, the 
real-time nature of the processes under 
control have to be considered as a funda¬ 
mental design parameter of the commu¬ 
nications systems and the computer net¬ 
working.” Besides this important 
property, or “real timeliness,” the authors 
list a number of other characteristics 
such as fault tolerance and redundancy, 
maintainability, expandability, and prior¬ 
itization of information. 

The complicated architecture of a CIM 
environment and the variety of require¬ 
ments for the communication system 
lead the authors to warn that “a single 
cable running throughout the plant, being 
utilized by all devices and all computers, 
in practice ... is not the right solution.” 


An alternative hierarchical model for al¬ 
most every network in recent years takes 
the form of the ISO/OSI (International 
Standards Organization/Open Systems 
Interconnection) reference model. The 
authors present all seven layers and ex¬ 
plain the notions of protocols and ser¬ 
vices at the end of the introduction. 

The authors assume that a primary 
property of a communication system in 
factory automation (as opposed to office 
automation) is its real timeliness. They 
outline two groups of typical LAN prop¬ 
erties that characterize alternative solu¬ 
tions or choices of technologies. The first 
group, which represents a static view of 
the network, contains typical topologies 
and typical transmission media. The sec¬ 
ond group contains more dynamic char¬ 
acteristics such as signaling modes 
(baseband and broadband), encoding 
techniques for a physical layer, protocols 
based on carrier-sensitive multiple access 
with collision detection (CSMA/CD), 
and token access methods for the data- 
link layer. 

You can easily find all this informa¬ 
tion in any book on LANs (for example, 
W. Stallings, Local Networks , Macmill¬ 
an, New York, 1990, or L. Hutchinson, 
Local Area Network Architectures, Addi- 
son-Wesley, Reading, Mass., 1988). 
Readers with a background in network¬ 
ing may skip this part without any loss. 
However, two important points related to 
industrial networks are worth mention¬ 
ing. Both concern certain disadvantages 
of CSMA/CD methods for data commu¬ 
nications in industrial environments. 

First, if.you consider the amount of 
time any station must wait before data 
transmission can be established (as a re¬ 
sult of access contention), “in CSMA/CD 
the delay time has theoretically no upper 
bound.” Therefore, “for process control 
and other real-time applications, this non- 
deterministic behavior is unacceptable.” 

Second, considering further problems 
with access to a medium, “if priorities 
are required, as they may be in [a] manu¬ 
facturing or process control, real-time 
environment, these can be accommo¬ 
dated.” This is true only for token-based 
methods. 

MAP (Manufacturing Automation Pro¬ 
tocol) is described as the most important 
practical solution of a communication 
system. In this description, the basic 
properties of lowest and highest MAP 
layers are mentioned as the most vital for 
industrial networks that meet real-time 
requirements. In particular, FTAM (File 
Transfer and Management) and MMS 


(Manufacturing Message Specification) 
protocols are described for the applica¬ 
tion layer. Two MAP variants, MAP/ 
EPA (Enhanced Performance Architec¬ 
ture) and Mini-MAP (collapsed and re¬ 
duced to three layers), are important 
from this point of view. 

The authors devote a separate chapter 
to a new concept of the lowest layer in a 
MAP hierarchy, the so-called field bus, 
which may replace existing practices. 
Because it is critical that real time be 
taken into account at the lowest levels of 
factory automation, current solutions — 
which emerged mostly in office environ¬ 
ments — are considered inappropriate by 
designers. However, this book only men¬ 
tions a set of requirements for these lay¬ 
ers in terms of field bus services. I would 
like to see several known and competi¬ 
tive solutions — for example, Mil-Std 
1533B, the Intel Bitbus (standardized by 
IEEE Project 1118), Siemens-backed 
Profibus, and French FIP (Factory Instru¬ 
mentation Protocol) — at least partially 
described. It would also be useful to see 
how they compare with the Proway (pro¬ 
cess data highway standard ) developed 
for process control industries ( ISA- 
S72.01, Instrument Society of America, 
1985). 

The book ends with bitter remarks 
about the practical usefulness of com¬ 
mercial MAP solutions (stating the in¬ 
compatibility of various products) and 
summarizes real-time features of data 
communications in a factory. 

This is one of the few books on the 
market that focuses on industrial (non¬ 
office) applications for LANs. (The other 
one I know about is D. Popovic and V.P. 
Bhatkar’s Distributed Computer Control 
for Industrial Automation, Marcel Dek- 
ker, New York, 1990.) It has value as a 
clear, comprehensible, systematic pre¬ 
sentation of basic concepts that may at¬ 
tract a broad audience. It is like a guide, 
containing an overview of the field. The 
only minor deficiency is the lack of a 
separate basic glossary. This elementary 
approach is the book’s weakness because 
it does not treat certain aspects in enough 
depth to be very useful for engineers. A 
new edition should include a section on 
recent research topics with a classical 
case study. This would make the book 
useful for serious academic courses. You 
should also note that software, a real 
problem in data communications, is not 
covered. 

Janusz Zalewski 

Southwest Texas State University 


June 1991 






tie the facts, but having opinions is an art.” 

Charles McCabe, San Francisco Chronicle 
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Performance analysis ratholes 

or 


How to stall a performance presentation 

Raj Jain, Digital Equipment Corporation 


System buyers, sellers, managers, and 
designers often choose among alternative 
products based on performance data. 
Whether you are a consumer or a suppli¬ 
er of performance information, you 
should be aware of four areas of discus¬ 
sion that can lead a performance presen¬ 
tation into endless debate. Figure 1 
shows these “ratholes” in the order of 
their time consumption (from large to 
small). 

Presenting this cartoon at the begin¬ 
ning of performance presentations helps 
to capture audience attention and also en¬ 
sures that no one will waste time in rat¬ 
holes. If your competitor is making a 
presentation, you can use these ratholes 
to your advantage by raising issues in¬ 
volving one of the four areas. If you are 
making the presentation and a listener 
raises an issue, you can use the cartoon 
to point out that this well-known rathole 
is not worth the audience’s time. 

The first and most commonly raised 
issue is the benchmark (or work load) 
used in performance analysis. The appli¬ 
cability of any benchmark is always open 
to question. For example, if the presenter 
has used long jobs (or long files, packets, 
transactions, or commands) to bench¬ 
mark a system, you may point out that 
most jobs in the real world are small. 

On the other hand, if the presenter has 
used short jobs, you can point out that 
measuring short-job performance is not 
very meaningful. The long jobs are really 
important because they consume so 
many resources. Other features of the 
benchmark,, such as the distribution (ex¬ 
ponential versus normal versus uniform) 
can be called into question in a similar 
fashion. 

The next issue is performance criteria, 
or metrics. If the presenter has used a 
throughput metric like MIPS (million in¬ 



holes (reproduced with permission 
from John Wiley & Sons 1 ). 


structions per second), TPS (transactions 
per second), bps (bits per second), or pps 
(packets per second), point out that it is 
the response time that counts, not the 
rate. (The response time includes com¬ 
pleting one job, executing one transac¬ 
tion, or transferring one file.) If the pre¬ 
senter has used the response time, assert 
that the total work done — and hence the 
throughput — is more important. If the 
presenter has used both, state that reli¬ 
ability, availability, and serviceability 
factors are obviously the most important. 


The third issue is the configuration 
used in the analysis. If the presenter has 
used a system with one disk drive, you 
may point out that most systems have 
two drives. If the presenter has used two 
drives, you can cite the trend toward 
diskless systems and future systems with 
no drives. 

Finally, the level of detail that accom¬ 
panies system analysis is important. In 
particular, you can question the simplici¬ 
ty of any analysis. For example, if the 
disks in a simulation model are repre¬ 
sented as simple queues, you can point 
out that the model should have more 
disk-arm movement detail. On the other 
hand, if the model is detailed, you can 
say it is too complex to be useful. 

Incidentally, the word presentation 
here includes advertisements, reports, 
and product literature. In such cases, you 
can raise the issue by writing a letter to 
the editor of any well-knbwn publication. 

Performance analysis ratholes apply 
not only to networks, databases, and PCs 
but also to devices, algorithms, and ap¬ 
plications. The four ratholes discussed 
here are the most important part of the 
analysis. A different choice of bench¬ 
mark, metric, configuration, and specific 
detail may change the study’s conclu¬ 
sion. Therefore, you should be careful in 
your selection and perform a sensitivity 
analysis to determine whether the con¬ 
clusions would change if the analysis 
were performed in a slightly different 
setting. 

Reference 
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The Hague, May 4-8,1992 
Netherlands Congress Centre 


1992 International Conference on 

COMPUTER SYSTEMS 
and SOFTWARE ENGINEERING 


features 

* Keynote addresses on main themes: 

- Computers and Optimization 

- Parallel Processing 

- Computational Algebra 

* State of the art Lectures by prominent 
scientists and engineers 

* Invited and Regular Papers 

* Student Paper Contest 

* Tutorials on five main topics 

* Technical Exhibition, Visits 

tutorials 

1. Parallel Computing and Neural Nets 

2. Artificial Intelligence 

3. Computational Algebra 

4. Languages and Specification 

5. Optimization and Programming 

Submission of papers and posters 

Authors are invited to submit papers and/or posters on 
any of the conference topics. Prospective authors of pa¬ 
pers should submit five clear and stapled copies of their 
contribution to the Program Chairman before 
Nov.lst’91, by regular mail. The paper should not be 
longer than twelve double spaced A4 pages and should 
conform to normal IEEE Proceedings standards. Ac¬ 
cepted papers of participating authors will be published 
in the Conference Proceedings by the IEEE Computer 
Society Press. 

Student papers will be treated as regular papers and will, 
in addition, be eligible for the best student paper award. 
Prospective authors of posters should submit a summary 
of their poster by Feb.lst’92. 

Notification of acceptance will be by Feb.l5th’92. 

Program Chair 

Prof. Patrick Dewilde 

Delft Univ. of Technology, Dept.of EE 

POB. 5031, 2600 GA Delft 

The Netherlands 

Fax: 31-15-623271 


Conference topics 

In addition to the main themes of the conference 
(Computers and Optimization, Parallel Processing 
and Computational Algebra), a further 
non-exhaustive list of topics is: 

Optimization Techniques, Compiler Design and 
Optimization, Scheduling, Partitioning, Clustering, 
Algorithms and Complexity, Computational Logic, 
Parallel Algorithms, Signal Processors, Architectural 
Design Techniques, Computer Aided Design, 

Networks and Communication, Optimal Routing, 

Neural Networks, Mathematical Programming, 

Medical Computing, Database Architectures, 

Optimal Control, Operations Research, Hardware 
and Complexity, Functional Languages, Systolic Arrays, 
Knowledge-based Systems, Simulation of Large 
Scale Systems, Silicon Compilation, Computer 
Graphics, Special Processors, Computers for 
Consumer Electronics, Consumer Products, 

Data Security, Genetic Algorithms, Standards. 

Special Sessions 

Participants are invited to propose a program for special 
session (s). The proposal should be addressed to the Pro¬ 
gram Committee Chairman before Nov. 1st,’91 and con¬ 
tain name, address and fax number of the organizer, title 
and name of session chairperson and a list of at most 
four contributions. 

Deadlines and Key Dates 

Submission of manuscripts Nov. 1, 1991 

Notification of acceptance Jan. 15, 1991 

Final manuscript/poster proposal Feb. 1, 1992 
Conference Tutorials May 4, 1992 

Conference Sessions May 5-7, 1992 

Visits May 8, 1992 


To obtain further information on the Conference, 
please write to the Program Chairman. 
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